draft-ietf-ccamp-gmpls-sonet-sdh-03.txt   draft-ietf-ccamp-gmpls-sonet-sdh-04.txt 
CCAMP Working Group Eric Mannie (Ebone) - Editor CCAMP Working Group Eric Mannie - Editor (KPNQwest)
Internet Draft Internet Draft
Expiration Date: June 2002 Stefan Ansorge (Alcatel) Expiration Date: October 2002 Stefan Ansorge (Alcatel)
Peter Ashwood-Smith (Nortel) Peter Ashwood-Smith (Nortel)
Ayan Banerjee (Calient) Ayan Banerjee (Calient)
Lou Berger (Movaz) Lou Berger (Movaz)
Greg Bernstein (Ciena) Greg Bernstein (Ciena)
Angela Chiu (Celion) Angela Chiu (Celion)
John Drake (Calient) John Drake (Calient)
Yanhe Fan (Axiowave) Yanhe Fan (Axiowave)
Michele Fontana (Alcatel) Michele Fontana (Alcatel)
Gert Grammel (Alcatel) Gert Grammel (Alcatel)
Juergen Heiles(Siemens) Juergen Heiles(Siemens)
skipping to change at line 34 skipping to change at line 34
Bala Rajagopalan (Tellium) Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper) Yakov Rekhter (Juniper)
Debanjan Saha (Tellium) Debanjan Saha (Tellium)
Vishal Sharma (Metanoia) Vishal Sharma (Metanoia)
George Swallow (Cisco) George Swallow (Cisco)
Z. Bo Tang (Tellium) Z. Bo Tang (Tellium)
Eve Varma (Lucent) Eve Varma (Lucent)
Maarten Vissers (Lucent) Maarten Vissers (Lucent)
Yangguang Xu (Lucent) Yangguang Xu (Lucent)
December 2001 April 2002
GMPLS Extensions for SONET and SDH Control GMPLS Extensions for SONET and SDH Control
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt draft-ietf-ccamp-gmpls-sonet-sdh-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts. also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
E. Mannie Editor 1 E. Mannie Editor 1
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document is a companion to the Generalized MPLS signaling This document is a companion to the Generalized MPLS signaling
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines
the SONET/SDH technology specific information needed when using the SONET/SDH technology specific information needed when using
skipping to change at line 107 skipping to change at line 107
concatenation and transparency. Some extra non-standard concatenation and transparency. Some extra non-standard
capabilities are defined in [GMPLS-SONET-SDH-EXT]. Other documents capabilities are defined in [GMPLS-SONET-SDH-EXT]. Other documents
could further enhance this set of capabilities in the future. For could further enhance this set of capabilities in the future. For
instance, signaling for SDH over PDH (ITU-T G.832), or sub-STM-0 instance, signaling for SDH over PDH (ITU-T G.832), or sub-STM-0
(ITU-T G.708) interfaces could be defined. (ITU-T G.708) interfaces could be defined.
The traffic parameters defined hereafter MUST be used when The traffic parameters defined hereafter MUST be used when
SONET/SDH is specified in the LSP Encoding Type field of a SONET/SDH is specified in the LSP Encoding Type field of a
Generalized Label Request [GMPLS-SIG]. Generalized Label Request [GMPLS-SIG].
E. Mannie Editor Internet-Draft June 2002 2 E. Mannie Editor Internet-Draft October 2002 2
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
A SONET signal which has an identical SDH signal SHOULD be
requested using the same traffic parameters as for the equivalent
SDH signal, and will consequently use the SDH label.
2.1. SONET/SDH Traffic Parameters 2.1. SONET/SDH Traffic Parameters
The traffic parameters for SONET/SDH is organized as follows: The traffic parameters for SONET/SDH is organized as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | RCC | NCC | | Signal Type | RCC | NCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) | | NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparency (T) | | Transparency (T) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile (P) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Annex 1 defines examples of SONET and SDH signal coding. Annex 1 defines examples of SONET and SDH signal coding.
Signal Type (ST): 8 bits Signal Type (ST): 8 bits
This field indicates the type of Elementary Signal that This field indicates the type of Elementary Signal that
comprises the requested LSP. Several transforms can be applied comprises the requested LSP. Several transforms can be applied
successively on the Elementary Signal to build the Final Signal successively on the Elementary Signal to build the Final Signal
being actually requested for the LSP. being actually requested for the LSP.
skipping to change at line 159 skipping to change at line 157
- Third, some transparency can be optionally specified when - Third, some transparency can be optionally specified when
requesting a frame as signal rather than an SPE or VC based requesting a frame as signal rather than an SPE or VC based
signal (by using the Transparency field). signal (by using the Transparency field).
- Fourth, a multiplication (by using the Multiplier field) can be - Fourth, a multiplication (by using the Multiplier field) can be
optionally applied either directly on the Elementary Signal, or optionally applied either directly on the Elementary Signal, or
on the contiguously concatenated signal obtained from the first on the contiguously concatenated signal obtained from the first
phase, or on the virtually concatenated signal obtained from phase, or on the virtually concatenated signal obtained from
the second phase, or on these signals combined with some the second phase, or on these signals combined with some
transparency. transparency.
E. Mannie Editor Internet-Draft June 2002 3 E. Mannie Editor Internet-Draft October 2002 3
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Permitted Signal Type values for SONET/SDH are: Permitted Signal Type values for SONET/SDH are:
Value Type Value Type
----- ----------------- ----- -----------------
1 VT1.5 SPE / VC-11 1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12 2 VT2 SPE / VC-12
3 VT3 SPE 3 VT3 SPE
4 VT6 SPE / VC-2 4 VT6 SPE / VC-2
5 STS-1 SPE / VC-3 5 STS-1 SPE / VC-3
skipping to change at line 216 skipping to change at line 214
scope. A downstream node that doesnĘt support any of the scope. A downstream node that doesnĘt support any of the
concatenation types indicated by the field must refuse the LSP concatenation types indicated by the field must refuse the LSP
request. In particular, it must refuse the LSP request if it request. In particular, it must refuse the LSP request if it
doesnĘt support contiguous concatenation at all. doesnĘt support contiguous concatenation at all.
The upstream node knows which type of contiguous concatenation The upstream node knows which type of contiguous concatenation
the downstream node chosen by looking at the position indicated the downstream node chosen by looking at the position indicated
by the first label and the number of label(s) as returned by by the first label and the number of label(s) as returned by
the downstream node. the downstream node.
E. Mannie Editor Internet-Draft June 2002 4 E. Mannie Editor Internet-Draft October 2002 4
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
The entire field is set to zero to indicate that no contiguous The entire field is set to zero to indicate that no contiguous
concatenation is requested at all (default value). A non-zero concatenation is requested at all (default value). A non-zero
field indicates that some contiguous concatenation is field indicates that some contiguous concatenation is
requested. requested.
The following flag is defined: The following flag is defined:
Flag 1 (bit 1): Standard contiguous concatenation. Flag 1 (bit 1): Standard contiguous concatenation.
skipping to change at line 269 skipping to change at line 267
SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and
NCC set to 1. NCC set to 1.
This field is irrelevant if no contiguous concatenation is This field is irrelevant if no contiguous concatenation is
requested (RCC = 0), in that case it must be set to zero when requested (RCC = 0), in that case it must be set to zero when
send, and should be ignored when received. A RCC value send, and should be ignored when received. A RCC value
different from 0 must imply a number of components greater than different from 0 must imply a number of components greater than
1. The NCC value must be consistent with the type of contiguous 1. The NCC value must be consistent with the type of contiguous
concatenation being requested in the RCC field. concatenation being requested in the RCC field.
E. Mannie Editor Internet-Draft June 2002 5 E. Mannie Editor Internet-Draft October 2002 5
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Number of Virtual Components (NVC): 16 bits Number of Virtual Components (NVC): 16 bits
This field indicates the number of signals that are requested This field indicates the number of signals that are requested
to be virtually concatenated. These signals are all of the same to be virtually concatenated. These signals are all of the same
type by definition. They are Elementary Signal SPEs/VCs for type by definition. They are Elementary Signal SPEs/VCs for
which signal types are defined in this document, i.e. VT1.5 which signal types are defined in this document, i.e. VT1.5
SPE, VT2 SPE, VT3 SPE, VT6 SPE, STS-1 SPE, STS-3c SPE, VC-11, SPE, VT2 SPE, VT3 SPE, VT6 SPE, STS-1 SPE, STS-3c SPE, VC-11,
VC-12, VC-2, VC-3 or VC-4. VC-12, VC-2, VC-3 or VC-4.
skipping to change at line 295 skipping to change at line 293
can be virtually concatenated beyond the virtual concatenation as can be virtually concatenated beyond the virtual concatenation as
defined in T1.105/G.707. defined in T1.105/G.707.
Multiplier (MT): 16 bits Multiplier (MT): 16 bits
This field indicates the number of identical signals that are This field indicates the number of identical signals that are
requested for the LSP, i.e. that form the Final Signal. These requested for the LSP, i.e. that form the Final Signal. These
signals can be either identical Elementary Signals, or signals can be either identical Elementary Signals, or
identical contiguously concatenated signals, or identical identical contiguously concatenated signals, or identical
virtually concatenated signals. Note that all these signals virtually concatenated signals. Note that all these signals
belongs thus to the same LSP. belong thus to the same LSP.
The distinction between the components of multiple virtually The distinction between the components of multiple virtually
concatenated signals is done via the order of the labels that concatenated signals is done via the order of the labels that
are specified in the signaling. The first set of labels must are specified in the signaling. The first set of labels must
describe the first component (set of individual signals describe the first component (set of individual signals
belonging to the first virtual concatenated signal), the second belonging to the first virtual concatenated signal), the second
set must describe the second component (set of individual set must describe the second component (set of individual
signals belonging to the second virtual concatenated signal) signals belonging to the second virtual concatenated signal)
and so on. and so on.
skipping to change at line 327 skipping to change at line 325
Transparency, as defined from the point of view of this Transparency, as defined from the point of view of this
signaling specification, is only applicable to the fields in signaling specification, is only applicable to the fields in
the SONET/SDH frame overheads. In the SONET case, these are the the SONET/SDH frame overheads. In the SONET case, these are the
fields in the Section Overhead (SOH), and the Line Overhead fields in the Section Overhead (SOH), and the Line Overhead
(LOH). In the SDH case, these are the fields in the Regenerator (LOH). In the SDH case, these are the fields in the Regenerator
Section Overhead (RSOH), the Multiplex Section overhead (MSOH), Section Overhead (RSOH), the Multiplex Section overhead (MSOH),
and the pointer fields between the two. With SONET, the pointer and the pointer fields between the two. With SONET, the pointer
fields are part of the LOH. fields are part of the LOH.
E. Mannie Editor Internet-Draft June 2002 6 E. Mannie Editor Internet-Draft October 2002 6
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Note as well that transparency is only applicable when using Note as well that transparency is only applicable when using
the following Signal Types: STM-0, STM-1, STM-4, STM-16, STM- the following Signal Types: STM-0, STM-1, STM-4, STM-16, STM-
64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS- 64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-
768. At least one transparency type must be specified when 768. At least one transparency type must be specified when
requesting such a signal type. requesting such a signal type.
Transparency indicates precisely which fields in these Transparency indicates precisely which fields in these
overheads must be delivered unmodified at the other end of the overheads must be delivered unmodified at the other end of the
LSP. An ingress LSR requesting transparency will pass these LSP. An ingress LSR requesting transparency will pass these
skipping to change at line 374 skipping to change at line 372
pointers cannot be adjusted. When using Section/Regenerator pointers cannot be adjusted. When using Section/Regenerator
Section layer transparency all other flags must be ignored. Section layer transparency all other flags must be ignored.
Line/Multiplex Section layer transparency means that the Line/Multiplex Section layer transparency means that the
LOH/MSOH must be delivered unmodified. This implies that LOH/MSOH must be delivered unmodified. This implies that
pointers cannot be adjusted. pointers cannot be adjusted.
Refer to [GMPLS-SONET-SDH-EXT] for an extended set of transparency Refer to [GMPLS-SONET-SDH-EXT] for an extended set of transparency
types beyond the transparency types as defined in T1.105/G.707. types beyond the transparency types as defined in T1.105/G.707.
Profile (P)
This field is intended to indicate particular capabilities that
must be supported for the LSP, for example monitoring
capabilities.
No standard profile is currently defined and this field SHOULD
be set to zero when transmitted and SHOULD be ignored when
received.
E. Mannie Editor Internet-Draft October 2002 7
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
In the future TLV based extensions may be created.
2.2. RSVP-TE Details 2.2. RSVP-TE Details
For RSVP-TE, the SONET/SDH traffic parameters are carried in the For RSVP-TE, the SONET/SDH traffic parameters are carried in the
SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is
used both for SENDER_TSPEC object and FLOWSPEC objects. The used both for SENDER_TSPEC object and FLOWSPEC objects. The
contents of the objects is defined above in Section 2.1. The content of the objects is defined above in Section 2.1. The
objects have the following class and type: objects have the following class and type:
E. Mannie Editor Internet-Draft June 2002 7
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
For SONET ANSI T1.105 and SDH ITU-T G.707: For SONET ANSI T1.105 and SDH ITU-T G.707:
SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (TBA) SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (TBA)
SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (TBA) SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (TBA)
There is no Adspec associated with the SONET/SDH SENDER_TSPEC. There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
Either the Adspec is omitted or an int-serv Adspec with the Either the Adspec is omitted or an int-serv Adspec with the
Default General Characterization Parameters and Guaranteed Service Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC2210]. fragment is used, see [RFC2210].
For a particular sender in a session the contents of the FLOWSPEC For a particular sender in a session the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the object received in a Resv message SHOULD be identical to the
contents of the SENDER_TSPEC object received in the corresponding contents of the SENDER_TSPEC object received in the corresponding
Path message. If the objects do not match, a ResvErr message with Path message. If the objects do not match, a ResvErr message with
a "Traffic Control Error/Bad Flowspec value" error SHOULD be a "Traffic Control Error/Bad Flowspec value" error SHOULD be
generated. generated.
2.3. CR-LDP Details 2.3. CR-LDP Details
For CR-LDP, the SONET/SDH traffic parameters are carried in the For CR-LDP, the SONET/SDH traffic parameters are carried in the
SONET/SDH Traffic Parameters TLV. The contents of the TLV is SONET/SDH Traffic Parameters TLV. The content of the TLV is
defined above in Section 2.1. The header of the TLV has the defined above in Section 2.1. The header of the TLV has the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA. The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA.
3. SDH and SONET Labels 3. SDH and SONET Labels
SDH and SONET each define a multiplexing structure, with the SONET SDH and SONET each define a multiplexing structure, with the SONET
multiplex structure being a subset of the SDH multiplex structure. multiplex structure being a subset of the SDH multiplex structure.
These two structures are trees whose roots are respectively an These two structures are trees whose roots are respectively an
STM-N or an STS-N; and whose leaves are the signals that can be STM-N or an STS-N; and whose leaves are the signals that can be
transported via the time-slots and switched between time-slots, transported via the time-slots and switched between time-slots
i.e. a VC-x, a VT-x SPE or an STS SPE. An SDH/SONET label will within an ingress port and time-slots within an egress port, i.e.
identify the exact position of a particular signal in a a VC-x, a VT-x SPE or an STS-x SPE. An SDH/SONET label will
multiplexing structure. SDH and SONET labels are carried in the
Generalized Label per [GMPLS-RSVP] and [GMPLS-LDP]. E. Mannie Editor Internet-Draft October 2002 8
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
identify the exact position (i.e. first time-slot) of a particular
VC-x, VT-x SPE or STS-x SPE signal in a multiplexing structure.
SDH and SONET labels are carried in the Generalized Label per
[GMPLS-RSVP] and [GMPLS-LDP].
Note that by time-slots we mean the time-slots as they appear
logically and sequentially in the multiplex, not as they appear
after any possible interleaving.
These multiplexing structures will be used as naming trees to These multiplexing structures will be used as naming trees to
create unique multiplex entry names or labels. Since the SONET create unique multiplex entry names or labels. Since the SONET
multiplexing structure may be seen as a subset of the SDH multiplexing structure may be seen as a subset of the SDH
multiplexing structure, the same format of label is used for SDH multiplexing structure, the same format of label is used for SDH
and SONET. As explained in [GMPLS-SIG], a label does not identify and SONET. As explained in [GMPLS-SIG], a label does not identify
the "class" to which the label belongs. This is implicitly the "class" to which the label belongs. This is implicitly
determined by the link on which the label is used. determined by the link on which the label is used.
E. Mannie Editor Internet-Draft June 2002 8
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
In case of signal concatenation or multiplication, a list of In case of signal concatenation or multiplication, a list of
labels can appear in the Label field of a Generalized Label. labels can appear in the Label field of a Generalized Label.
In case of contiguous concatenation, only one label appears in the In case of contiguous concatenation, only one label appears in the
Label field. This label is the lowest signal of the contiguously Label field. This label identifies the lowest time-slot occupied
concatenated signal. By lowest signal we mean the one having the by the contiguously concatenated signal. By lowest time-slot we
lowest label when compared as integer values, i.e. the first mean the one having the lowest label when compared as integer
component signal of the concatenated signal encountered when values, i.e. the time-slot occupied by the first component signal
descending the tree. of the concatenated signal encountered when descending the tree.
In case of virtual concatenation, the explicit ordered list of all In case of virtual concatenation, the explicit ordered list of all
labels in the concatenation is given. Each label indicates a labels in the concatenation is given. Each label indicates the
component of the virtually concatenated signal. The order of the first time-slot occupied by a component of the virtually
labels must reflect the order of the payloads to concatenate (not concatenated signal. The order of the labels must reflect the
the physical order of time-slots). The above representation limits order of the payloads to concatenate (not the physical order of
virtual concatenation to remain within a single (component) link; time-slots). The above representation limits virtual concatenation
it imposes as such a restriction compared to the G.707/T1.105 to remain within a single (component) link; it imposes as such a
recommendations. restriction compared to the G.707/T1.105 recommendations.
The standard definition for virtual concatenation allows each
virtual concatenation components to travel over diverse paths.
Within GMPLS, virtual concatenation components must travel over
the same (component) link if they are part of the same LSP. This
is due to the way that labels are bound to a (component) link.
Note however, that the routing of components on different paths is
indeed equivalent to establishing different LSPs, each one having
its own route. Several LSPs can be initiated and terminated
between the same nodes and their corresponding components can then
be associated together (i.e. virtually concatenated).
In case of multiplication (i.e. using the multiplier transform), In case of multiplication (i.e. using the multiplier transform),
the explicit ordered list of all labels that take part in the the explicit ordered list of all labels that take part in the
Final Signal is given. In case of multiplication of virtually Final Signal is given. In case of multiplication of virtually
concatenated signals, the first set of labels indicates the first concatenated signals, the first set of labels indicates the time-
virtually concatenated signal, the second set of labels indicates slots occupied by the first virtually concatenated signal, the
the second virtually concatenated signal, and so on. The above second set of labels indicates the time-slots occupied by the
second virtually concatenated signal, and so on. The above
E. Mannie Editor Internet-Draft October 2002 9
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
representation limits multiplication to remain within a single representation limits multiplication to remain within a single
(component) link. (component) link.
The format of the label for SDH and/or SONET TDM-LSR link is: The format of the label for SDH and/or SONET TDM-LSR link is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S | U | K | L | M | | S | U | K | L | M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For SDH, this is an extension of the numbering scheme defined in This is an extension of the numbering scheme defined in G.707
G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the U sections 7.3.7 to 7.3.13, i.e. the (K, L, M) numbering. Note that
and K fields are not significant and must be set to zero. Only the the higher order numbering scheme defined in G.707 sections 7.3.1
S, L and M fields are significant for SONET and have a similar to 7.3.6 is not used here.
semantic as for SDH.
Each letter indicates a possible branch number starting at the Each letter indicates a possible branch number starting at the
parent node in the multiplex structure. Branches are considered as parent node in the multiplex structure. Branches are considered as
numbered in increasing order, starting from the top of the numbered in increasing order, starting from the top of the
multiplexing structure. The numbering starts at 1, zero is used to multiplexing structure. The numbering starts at 1, zero is used to
indicate a non-significant or ignored field. indicate a non-significant or ignored field.
When a field is not significant or ignored in a particular context When a field is not significant or ignored in a particular context
it MUST be set to zero when transmitted, and MUST be ignored when it MUST be set to zero when transmitted, and MUST be ignored when
received. received.
When hierarchical SDH/SONET LSPs are used, an LSP with a given When a hierarchy of SDH/SONET LSPs is used, an LSP with a given
bandwidth can be used to tunnel lower order LSPs. The higher bandwidth can be used to carry lower order LSPs. The higher order
SDH/SONET LSP behaves as a "virtual link" with a given bandwidth
(e.g. VC-3), it may also be used as a Forwarding Adjacency. A
lower order SDH/SONET LSP can be established through that higher
order LSP. Since a label is local to a (virtual) link, the highest
part of that label is non-significant and is set to zero, i.e. the
label is "0,0,0,L,M". Similarly, if the structure of the higher
order LSP is unknown or not relevant, the lowest part of that
label is non-significant and is set to zero, i.e. the label is
"S,U,K,0,0".
E. Mannie Editor Internet-Draft June 2002 9 For instance, a VC-3 LSP can be used to carry lower order LSPs. In
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 that case the labels allocated between the two ends of the VC-3
LSP for the lower order LSPs will have S, U and K set to zero,
i.e., non-significant, while L and M will be used to indicate the
signal allocated in that VC-3.
order SDH/SONET LSP behaves as a virtual link with a given In case of tunneling such as VC-4 containing VC-3 containing VC-
bandwidth (e.g. VC-3), it may also be used as a Forwarding 12/VC-11 where the SUKLM structure is not adequate to represent
Adjacency. A lower order SDH/SONET LSP can be established through the full signal structure, a hierarchical approach must be used,
that higher order LSP. Since a label is local to a (virtual) link, i.e. per layer network signaling.
the highest part of that label is non-significant and is set to
zero.
For instance, a VC-3 LSP can be advertised as a forwarding E. Mannie Editor Internet-Draft October 2002 10
adjacency. In that case the labels allocated between the two ends draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
of that LSP (i.e. for that "link") will have S, U and K set to
zero, i.e., non-significant, while L and M will be used to
indicate the signal allocated in that VC-3.
The possible values of S, U, K, L and M are defined as it follows: The possible values of S, U, K, L and M are defined as follows:
1. S is only significant for SDH STM-N (N>0) and SONET. It must 1. S=1->N is the index of a particular AUG-1/STS-3 inside an
be ignored for STM-0. S is the index of a particular AUG-1/STS- STM-N/STS-N multiplex. S is only significant for SDH STM-N (N>0)
1. S=1->N indicates a specific AUG-1/STS-1 inside an STM-N/STS-N and SONET STS-N (N>1) and must be 0 and ignored for STM-0 and
multiplex. For example, S=1 indicates the first AUG-1/STS-1, and STS-1.
S=N indicates the last AUG-1/STS-1 of this multiplex.
2. U is only significant for SDH STM-N (N>0) and must be ignored 2. U=1->3 is the index of a particular VC-3/STS-1 SPE within an
for STM-0 and SONET. It indicates a specific VC inside a given AUG-1/STS-3. U is only significant for SDH STM-N (N>0) and SONET
AUG-1. U=1 indicates a single VC-4, while U=2->4 indicates a STS-N (N>1) and must be 0 and ignored for STM-0 and STS-1.
specific VC-3 inside the given AUG-1.
3. K is only significant for SDH VC-4 and must be ignored in all 3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is
other cases. It indicates a specific branch of a VC-4. K=1 only significant for an SDH VC-4 structured in TUG-3s and must
indicates that the VC-4 is not further subdivided and contains a be 0 and ignored in all other cases.
C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. K is not
significant when the AUG-1 is divided into AU-3s.
4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. 4. L=1->7 is the index of a particular TUG-2/VT Group within a
It is not significant for an unstructured VC-4 (L=0). L=1 TUG-3, VC-3 or STS-1 SPE. L must be 0 and ignored in all other
indicates that the TUG-3/VC-3/STS-1 SPE is not further cases.
subdivided and contains a VC-3/C-3 in SDH or the equivalent in
SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
corresponding higher order signal.
5. M indicates a specific branch of a TUG-2/VT Group. It is not 5. M is the index of a particular VC-1/VT-1.5, VT-2 or VT-3 SPE
significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. within a TUG-2/VT Group. M=1->2 indicates a specific VT-3 SPE
M=1 indicates that the TUG-2/VT Group is not further subdivided
and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
inside the corresponding VT Group, these values MUST NOT be used inside the corresponding VT Group, these values MUST NOT be used
for SDH since there is no equivalent of VT-3 with SDH. M=4->6 for SDH since there is no equivalent of VT-3 with SDH. M=3->5
indicates a specific VC-12/VT-2 SPE inside the corresponding indicates a specific VC-12/VT-2 SPE inside the corresponding
TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE TUG-2/VT Group. M=6->9 indicates a specific VC-11/VT-1.5 SPE
inside the corresponding TUG-2/VT Group. Note that M=0 denotes inside the corresponding TUG-2/VT Group.
an unstructured VC-4, VC-3 or STS-1 SPE.
E. Mannie Editor Internet-Draft June 2002 10 Note that a label always has to be interpreted according the
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 SDH/SONET traffic parameters, i.e. a label by itself does not
allow knowing which signal is being requested (a label is
context sensitive).
The S encoding is summarized in the following table:
S SDH SONET
------------------------------------------------
0 other other
1 1st AUG-1 1st STS-3
2 2nd AUG-1 2nd STS-3
3 3rd AUG-1 3rd STS-3
4 4rd AUG-1 4rd STS-3
: : :
N Nth AUG-1 Nth STS-3
The U encoding is summarized in the following table:
U SDH AUG-1 SONET STS-3
-------------------------------------------------
0 other other
1 1st VC-3 1st STS-1 SPE
2 2nd VC-3 2nd STS-1 SPE
3 3rd VC-3 3rd STS-1 SPE
E. Mannie Editor Internet-Draft October 2002 11
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
The K encoding is summarized in the following table:
K SDH VC-4
---------------
0 other
1 1st TUG-3
2 2nd TUG-3
3 3rd TUG-3
The L encoding is summarized in the following table:
L SDH TUG-3 SDH VC-3 SONET STS-1 SPE
-------------------------------------------------
0 other other other
1 1st TUG-2 1st TUG-2 1st VTG
2 2nd TUG-2 2nd TUG-2 2nd VTG
3 3rd TUG-2 3rd TUG-2 3rd VTG
4 4th TUG-2 4th TUG-2 4th VTG
5 5th TUG-2 5th TUG-2 5th VTG
6 6th TUG-2 6th TUG-2 6th VTG
7 7th TUG-2 7th TUG-2 7th VTG
The M encoding is summarized in the following table: The M encoding is summarized in the following table:
M SDH SONET M SDH TUG-2 SONET VTG
---------------------------------------------------------- -------------------------------------------------
0 unstructured VC-4/VC-3 unstructured STS-1 SPE 0 other other
1 VC-2 VT-6 1 - 1st VT-3 SPE
2 - 1st VT-3 2 - 2nd VT-3 SPE
3 - 2nd VT-3 3 1st VC-12 1st VT-2 SPE
4 1st VC-12 1st VT-2 4 2nd VC-12 2nd VT-2 SPE
5 2nd VC-12 2nd VT-2 5 3rd VC-12 3rd VT-2 SPE
6 3rd VC-12 3rd VT-2 6 1st VC-11 1st VT-1.5 SPE
7 1st VC-11 1st VT-1.5 7 2nd VC-11 2nd VT-1.5 SPE
8 2nd VC-11 2nd VT-1.5 8 3rd VC-11 3rd VT-1.5 SPE
9 3rd VC-11 3rd VT-1.5 9 4th VC-11 4th VT-1.5 SPE
10 4th VC-11 4th VT-1.5
Examples of labels: Examples of labels:
Example 1: S>0, U=1, K=1, L=0, M=0 Example 1: the label for the VC-4/STS-3c in the Sth AUG-1/STS-3
Denotes the unstructured VC-4 of the Sth AUG-1. is: S>0, U=0, K=0, L=0, M=0.
Example 2: S>0, U=1, K>1, L=1, M=0 Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
Example 3: S>0, U=0, K=0, L=0, M=0 Example 3: the label for the Uth-1 VC-3/STS-1 SPE within the Sth
Denotes the unstructured SPE of the Sth STS-1. AUG-1/STS-3 is: S>0, U>0, K=0, L=0, M=0.
Example 4: S>0, U=0, K=0, L>1, M=1 Example 4: the label for the VC-2/VT-6 in the Lth-1 TUG-2/VT Group
Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1. in the Uth-1 VC-3/STS-1 SPE within the Sth AUG-1/STS-3 is: S>0,
U>0, K=0, L>0, M=0.
Example 5: S>0, U=0, K=0, L>1, M=9 E. Mannie Editor Internet-Draft October 2002 12
Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1. draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Example 5: the label for the 3rd VC-11/VT-1.5 in the Lth-1 TUG-
2/VT Group within the Uth-1 VC-3/STS-1 SPE within the Sth AUG-
1/STS-3 is: S>0, U>0, K=0, L>0, M=8.
Example 6: the label for the VC-4-4c/STS-12c which uses the 9th
AUG-1/STS-3 as its first timeslot is: S=9, U=0, K=0, L=0, M=0.
In case of contiguous concatenation, the label that is used is the In case of contiguous concatenation, the label that is used is the
lowest label of the contiguously concatenated signal as explained lowest label of the contiguously concatenated signal as explained
before. The higher part of the label indicates where the signal before. The higher part of the label indicates where the signal
starts and the lowest part is not significant. For instance, when starts and the lowest part is not significant.
requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.
In case of STM-0, the values of S, U and K must be equal to zero
according to the field coding rules. For instance, when requesting
an unstructured VC-3 in an STM-0 the label is S=0, U=0, K=0, L=1,
M=0.
In case of STS-3c SPE, the value of S is the index of the first In case of STM-0/STS-1, the values of S, U and K must be equal to
STS-1 of the STS-3c SPE in the SONET multiplex where SPEs are zero according to the field coding rules. For instance, when
numbered from 1 to N (before any interleaving). requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0,
M=0. When requesting a VC-11 in a VC-3 in an STM-0 the label is
S=0, U=0, K=0, L>0, M=6..9.
When a transparent concatenated STM-N/STS-3*N (N=1, 4, 16, 64, When a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is
256) is requested, the label is coded as for the case of requested, the label is not applicable and is set to zero.
contiguous concatenation and with S=1. I.e. S=1, U=0, K=0, L=0,
M=0.
E. Mannie Editor Internet-Draft June 2002 11 Refer to [GMPLS-SONET-SDH-EXT] for the label for the extended set
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 of transparency types beyond the transparency types as defined in
T1.105/G.707.
4. Acknowledgments 4. Acknowledgments
Valuable comments and input were received from many people. Valuable comments and input were received from many people, and
particularly on the CCAMP mailing list where outstanding
discussions took place.
5. Security Considerations 5. Security Considerations
This draft introduces no new security considerations to either This draft introduces no new security considerations to either
[GMPLS-RSVP] or [GMPLS-LDP]. [GMPLS-RSVP] or [GMPLS-LDP]. GMPLS security is described in
section 11 of [GMPLS-SIG], in [CR-LDP] and in [RSVP-TE].
6. References 6. References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft, Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-07.txt, draft-ietf-mpls-generalized-signaling-07.txt,
November 2001. November 2001.
[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
CR-LDP Extensions", Internet Draft, CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-05.txt, draft-ietf-mpls-generalized-cr-ldp-05.txt,
November 2001. November 2001.
[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS
Signaling - RSVP-TE Extensions", Internet Draft, Signaling - RSVP-TE Extensions", Internet Draft,
E. Mannie Editor Internet-Draft October 2002 13
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
draft-ietf-mpls-generalized-rsvp-te-06.txt, draft-ietf-mpls-generalized-rsvp-te-06.txt,
November 2001. November 2001.
[GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to [GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to
control non-standard SONET and SDH features", control non-standard SONET and SDH features",
Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh- Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-
extensions-01.txt, December 2001. extensions-02.txt, April 2002.
[GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet
Draft, draft-ietf-ccamp-gmpls-architecture-01.txt, Draft, draft-ietf-ccamp-gmpls-architecture-02.txt,
November 2001. March 2002.
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
RFC3212, January, 2002.
[RSVP-TE] Awduche, et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997. Services," RFC 2210, September 1997.
7. Authors Addresses 7. Authors Addresses
Stefan Ansorge Stefan Ansorge
Alcatel Alcatel
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
Phone: +49 7 11 821 337 44 Phone: +49 7 11 821 337 44
Email: Stefan.ansorge@alcatel.de Email: Stefan.ansorge@alcatel.de
E. Mannie Editor Internet-Draft June 2002 12
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com Email: petera@nortelnetworks.com
Ayan Banerjee Ayan Banerjee
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972-3645 Phone: +1 408 972-3645
Email: abanerjee@calient.net Email: abanerjee@calient.net
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
E. Mannie Editor Internet-Draft October 2002 14
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
Greg Bernstein Greg Bernstein
Ciena Corporation Ciena Corporation
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 94014 Cupertino, CA 94014
Phone: +1 408 366 4713 Phone: +1 408 366 4713
Email: greg@ciena.com Email: greg@ciena.com
skipping to change at line 712 skipping to change at line 805
Phone: +1 408 972 3720 Phone: +1 408 972 3720
Email: jdrake@calient.net Email: jdrake@calient.net
Yanhe Fan Yanhe Fan
Axiowave Networks, Inc. Axiowave Networks, Inc.
100 Nickerson Road 100 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
Phone: +1 508 460 6969 Ext. 627 Phone: +1 508 460 6969 Ext. 627
Email: yfan@axiowave.com Email: yfan@axiowave.com
E. Mannie Editor Internet-Draft June 2002 13
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Michele Fontana Michele Fontana
Alcatel Alcatel
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Phone: +39 039 686-7053 Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it Email: michele.fontana@netit.alcatel.it
Gert Grammel Gert Grammel
Alcatel Alcatel
Via Trento 30, Via Trento 30,
skipping to change at line 736 skipping to change at line 826
Phone: +39 039 686-7060 Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it Email: gert.grammel@netit.alcatel.it
Juergen Heiles Juergen Heiles
Siemens AG Siemens AG
Hofmannstr. 51 Hofmannstr. 51
D-81379 Munich, Germany D-81379 Munich, Germany
Phone: +49 89 7 22 - 4 86 64 Phone: +49 89 7 22 - 4 86 64
Email: Juergen.Heiles@icn.siemens.de Email: Juergen.Heiles@icn.siemens.de
E. Mannie Editor Internet-Draft October 2002 15
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Suresh Katukam Suresh Katukam
Cisco Systems Cisco Systems
1450 N. McDowell Blvd, 1450 N. McDowell Blvd,
Petaluma, CA 94954-6515 USA Petaluma, CA 94954-6515 USA
e-mail: skatukam@cisco.com e-mail: skatukam@cisco.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Jonathan P. Lang Jonathan P. Lang
Calient Networks Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117
Email: jplang@calient.net Email: jplang@calient.net
Zhi-Wei Lin Zhi-Wei Lin
Lucent
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733-3030 Holmdel, NJ 07733-3030
Phone: +1 732 949 5141 Phone: +1 732 949 5141
Email: zwlin@lucent.com Email: zwlin@lucent.com
Ben Mack-Crane Ben Mack-Crane
Tellabs Tellabs
Email: Ben.Mack-Crane@tellabs.com Email: Ben.Mack-Crane@tellabs.com
E. Mannie Editor Internet-Draft June 2002 14 Eric Mannie Editor & Primary Point of Contact
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 KPNQwest
Eric Mannie
EBONE
Terhulpsesteenweg 6A Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium 1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52 Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52 Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18 Fax: +32 2 658 51 18
Email: eric.mannie@ebone.com Email: eric.mannie@kpnqwest.com
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be Email: Dimitri.Papadimitriou@alcatel.be
Dimitrios Pendarakis
Tellium
Phone: +1 (732) 923-4254
Email: dpendarakis@tellium.com
Mike Raftelis Mike Raftelis
White Rock Networks White Rock Networks
18111 Preston Road Suite 900 18111 Preston Road Suite 900
Dallas, TX 75252 Dallas, TX 75252
E. Mannie Editor Internet-Draft October 2002 16
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Phone: +1 (972)588-3728 Phone: +1 (972)588-3728
Fax: +1 (972)588-3701 Fax: +1 (972)588-3701
Email: Mraftelis@WhiteRockNetworks.com Email: Mraftelis@WhiteRockNetworks.com
Bala Rajagopalan Bala Rajagopalan
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4237 Phone: +1 732 923 4237
skipping to change at line 819 skipping to change at line 919
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: dsaha@tellium.com Email: dsaha@tellium.com
Vishal Sharma Vishal Sharma
Metanoia, Inc. Metanoia, Inc.
335 Elan Village Lane 335 Elan Village Lane
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 943 1794 Phone: +1 408 943 1794
Email: vsharma87@yahoo.com Email: vsharma87@yahoo.com
E. Mannie Editor Internet-Draft June 2002 15
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Voice: +1 978 244 8143 Voice: +1 978 244 8143
Email: swallow@cisco.com Email: swallow@cisco.com
Z. Bo Tang Z. Bo Tang
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4231 Phone: +1 732 923 4231
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Eve Varma Eve Varma
Lucent
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733-3030 Holmdel, NJ 07733-3030
Phone: +1 732 949 8559 Phone: +1 732 949 8559
Email: evarma@lucent.com Email: evarma@lucent.com
E. Mannie Editor Internet-Draft October 2002 17
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Maarten Vissers Maarten Vissers
Lucent
Botterstraat 45 Botterstraat 45
Postbus 18 Postbus 18
1270 AA Huizen, Netherlands 1270 AA Huizen, Netherlands
Email: mvissers@lucent.com Email: mvissers@lucent.com
Yangguang Xu Yangguang Xu
Lucent
21-2A41, 1600 Osgood Street 21-2A41, 1600 Osgood Street
North Andover, MA 01845 North Andover, MA 01845
Email: xuyg@lucent.com Email: xuyg@lucent.com
E. Mannie Editor Internet-Draft June 2002 16 E. Mannie Editor Internet-Draft October 2002 18
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Appendix 1 - Signal Type Values Extension For VC-3 Appendix 1 - Signal Type Values Extension For VC-3
This appendix defines the following optional additional Signal This appendix defines the following optional additional Signal
Type value for the Signal Type field of section 2.1: Type value for the Signal Type field of section 2.1:
Value Type Value Type
----- --------------------- ----- ---------------------
20 "VC-3 via AU-3 at the end" 20 "VC-3 via AU-3 at the end"
skipping to change at line 888 skipping to change at line 991
its incoming interface before demultiplexing and then switching its incoming interface before demultiplexing and then switching
the content with its switch fabric. the content with its switch fabric.
In that case it is useful to indicate that the VC-3 LSP must be In that case it is useful to indicate that the VC-3 LSP must be
terminated at the end in the AU-3 branch instead of the TU-3 terminated at the end in the AU-3 branch instead of the TU-3
branch. branch.
This is achieved by using the "VC-3 via AU-3 at the end" signal This is achieved by using the "VC-3 via AU-3 at the end" signal
type. This information can be used, for instance, by the type. This information can be used, for instance, by the
penultimate LSR to switch an incoming VC-3 received in any branch penultimate LSR to switch an incoming VC-3 received in any branch
to the TU-3 branch on the outgoing interface to the destination to the AU-3 branch on the outgoing interface to the destination
LSR. LSR.
The "VC-3 via AU-3 at the end" signal type does not imply that the The "VC-3 via AU-3 at the end" signal type does not imply that the
VC-3 must be switched via the AU-3 branch at some other places in VC-3 must be switched via the AU-3 branch at some other places in
the network. The VC-3 signal type just indicates that a VC-3 in the network. The VC-3 signal type just indicates that a VC-3 in
any branch is suitable. any branch is suitable.
E. Mannie Editor Internet-Draft June 2002 17 E. Mannie Editor Internet-Draft October 2002 19
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Annex 1 - Examples Annex 1 - Examples
This annex defines examples of SONET and SDH signal coding. Their This annex defines examples of SONET and SDH signal coding. Their
objective is to help the reader to understand how works the traffic objective is to help the reader to understand how works the traffic
parameter coding and not to give examples of typical SONET or SDH parameter coding and not to give examples of typical SONET or SDH
signals. signals.
As stated above, signal types are Elementary Signals to which As stated above, signal types are Elementary Signals to which
successive concatenation, multiplication and transparency successive concatenation, multiplication and transparency
skipping to change at line 929 skipping to change at line 1032
3. A VC-4-16c signal is formed by the application of RCC with flag 3. A VC-4-16c signal is formed by the application of RCC with flag
1 (standard contiguous concatenation), NCC with value 16, NVC with 1 (standard contiguous concatenation), NCC with value 16, NVC with
value 0, MT with value 1 and T with value 0 to a VC-4 Elementary value 0, MT with value 1 and T with value 0 to a VC-4 Elementary
Signal. Signal.
4. An STM-16 signal with Multiplex Section layer transparency is 4. An STM-16 signal with Multiplex Section layer transparency is
formed by the application of RCC with value 0, NCC with value 0, formed by the application of RCC with value 0, NCC with value 0,
NVC with value 0, MT with value 1 and T with flag 2 to an STM-16 NVC with value 0, MT with value 1 and T with flag 2 to an STM-16
Elementary Signal. Elementary Signal.
5. An STM-4c signal (i.e. VC-4-4C with the transport overhead) 5. An STM-4 signal with Multiplex Section layer transparency is
with Multiplex Section layer transparency is formed by the formed by the application of RCC with flag 0, NCC with value 0,
application of RCC with flag 1, NCC with value 1, NVC with value NVC with value 0, MT with value 1 and T with flag 2 applied to an
0, MT with value 1 and T with flag 2 applied to an STM-4 STM-4 Elementary Signal.
Elementary Signal.
6. An STM-256c signal with Multiplex Section layer transparency is 6. An STM-256 signal with Multiplex Section layer transparency is
formed by the application of RCC with flag 1, NCC with value 1, formed by the application of RCC with flag 0, NCC with value 0,
NVC with value 0, MT with value 1 and T with flag 2 applied to an NVC with value 0, MT with value 1 and T with flag 2 applied to an
STM-256 Elementary Signal. STM-256 Elementary Signal.
7. An STS-1 SPE signal is formed by the application of RCC with 7. An STS-1 SPE signal is formed by the application of RCC with
value 0, NCC with value 0, NVC with value 0, MT with value 1 and T value 0, NCC with value 0, NVC with value 0, MT with value 1 and T
with value 0 to an STS-1 SPE Elementary Signal. with value 0 to an STS-1 SPE Elementary Signal.
8. An STS-3c SPE signal is formed by the application of RCC with 8. An STS-3c SPE signal is formed by the application of RCC with
value 0 (no contiguous concatenation), NCC with value 0, NVC with value 0 (no contiguous concatenation), NCC with value 0, NVC with
value 0, MT with value 1 and T with value 0 to an STS-3c SPE value 0, MT with value 1 and T with value 0 to an STS-3c SPE
Elementary Signal. Elementary Signal.
9. An STS-48c SPE signal is formed by the application of RCC with 9. An STS-48c SPE signal is formed by the application of RCC with
flag 1 (standard contiguous concatenation), NCC with value 16, NVC flag 1 (standard contiguous concatenation), NCC with value 16, NVC
with value 0, MT with value 1 and T with value 0 to an STS-3c SPE with value 0, MT with value 1 and T with value 0 to an STS-3c SPE
Elementary Signal. Elementary Signal.
E. Mannie Editor Internet-Draft June 2002 18 E. Mannie Editor Internet-Draft October 2002 20
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
10. An STS-1-3v SPE signal is formed by the application of RCC 10. An STS-1-3v SPE signal is formed by the application of RCC
with value 0, NVC with value 3 (virtual concatenation of 3 with value 0, NVC with value 3 (virtual concatenation of 3
components), MT with value 1 and T with value 0 to an STS-1 SPE components), MT with value 1 and T with value 0 to an STS-1 SPE
Elementary Signal. Elementary Signal.
11. An STS-3c-9v SPE signal is formed by the application of RCC 11. An STS-3c-9v SPE signal is formed by the application of RCC
with value 0, NCC with value 0, NVC with value 9 (virtual with value 0, NCC with value 0, NVC with value 9 (virtual
concatenation of 9 STS-3c), MT with value 1 and T with value 0 to concatenation of 9 STS-3c), MT with value 1 and T with value 0 to
an STS-3c SPE Elementary Signal. an STS-3c SPE Elementary Signal.
skipping to change at line 979 skipping to change at line 1081
MT with value 1 and T with flag 1 to an STS-12 Elementary Signal. MT with value 1 and T with flag 1 to an STS-12 Elementary Signal.
13. 3 x STS-768c SPE signal is formed by the application of RCC 13. 3 x STS-768c SPE signal is formed by the application of RCC
with flag 1, NCC with value 256, NVC with value 0, MT with value with flag 1, NCC with value 256, NVC with value 0, MT with value
3, and T with value 0 to an STS-3c SPE Elementary Signal. 3, and T with value 0 to an STS-3c SPE Elementary Signal.
14. 5 x VC-4-13v composed signal is formed by the application of 14. 5 x VC-4-13v composed signal is formed by the application of
RCC with value 0, NVC with value 13, MT with value 5 and T with RCC with value 0, NVC with value 13, MT with value 5 and T with
value 0 to a VC-4 Elementary Signal. value 0 to a VC-4 Elementary Signal.
E. Mannie Editor Internet-Draft June 2002 19 The encoding of these examples is summarized in the following
table:
Signal ST RCC NCC NVC MT T
--------------------------------------------------------
VC-4 6 0 0 0 1 0
VC-4-7v 6 0 0 7 1 0
VC-4-16c 6 1 16 0 1 0
STM-16 MS transparent 10 0 0 0 1 2
STM-4 MS transparent 9 0 0 0 1 2
STM-256 MS transparent 12 0 0 0 1 2
STS-1 SPE 5 0 0 0 1 0
STS-3c SPE 6 0 0 0 1 0
STS-48c SPE 6 1 16 0 1 0
STS-1-3v SPE 5 0 0 3 1 0
STS-3c-9v SPE 6 0 0 9 1 0
STS-12 Section transparent 9 0 0 0 1 1
3 x STS-768c SPE 6 1 256 0 3 0
5 x VC-4-13v 6 0 0 13 5 0
E. Mannie Editor Internet-Draft October 2002 21
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/