draft-ietf-ccamp-rfc3946bis-00.txt   draft-ietf-ccamp-rfc3946bis-01.txt 
Network Working Group E. Mannie Network Working Group E. Mannie
Internet Draft Consultant Internet Draft Consultant
Replaces RFC 3946 D. Papadimitriou Replaces RFC 3946 D. Papadimitriou
Category: Standard Track Alcatel Category: Standard Track Alcatel
Expiration Date: April 2006 Expiration Date: May 2006
November 2005 December 2005
Generalized Multi-Protocol Label Switching (GMPLS) Extensions Generalized Multi-Protocol Label Switching (GMPLS) Extensions
for Synchronous Optical Network (SONET) for Synchronous Optical Network (SONET)
and Synchronous Digital Hierarchy (SDH) Control and Synchronous Digital Hierarchy (SDH) Control
draft-ietf-ccamp-rfc3946bis-00.txt draft-ietf-ccamp-rfc3946bis-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 293 skipping to change at line 293
signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1. signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1.
The NCC value must be consistent with the type of contiguous The NCC value must be consistent with the type of contiguous
concatenation being requested in the RCC field. In particular, concatenation being requested in the RCC field. In particular,
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
sent, and should be ignored when received. A RCC value different sent, and should be ignored when received. A RCC value different
from 0 implies a number of contiguous components greater than or from 0 implies a number of contiguous components greater than or
equal to 1. equal to 1.
<BEGIN NOTE for explanation. To be removed before publication as Note 3: Following these rules, when requesting a VC-4 signal, the
an RFC> RCC and the NCC values SHOULD be set to 0 whereas for an STS-3c
SPE signal, the RCC and the NCC values SHOULD be set 1. However,
Update from RFC 3946 from "greater than 1" to "greater than or if local conditions allow and since the setting of the RCC and NCC
equal to 1". The original "greater than" aimed to be interpreted
as "greater than or equal" and not "strictly greater than".
<END NOTE>
Note 1: Following these rules, when requesting a VC-4 signal, the
RCC and the NCC values must be set to 0 whereas for an STS-3c SPE
signal, the RCC and the NCC values must be set 1. However, if
local conditions allow and since the setting of the RCC and NCC
values is locally driven, the requesting upstream node MAY set the values is locally driven, the requesting upstream node MAY set the
RCC and NCC values to either SDH or SONET settings without RCC and NCC values to either SDH or SONET settings without
impacting the function. Moreover, the downstream node SHOULD impacting the function. Moreover, the downstream node SHOULD
accept the requested values if local conditions allow. If these accept the requested values if local conditions allow. If these
values can not be supported, the receiver downstream node MUST values cannot be supported, the receiver downstream node SHOULD
generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, generate a PathErr/NOTIFICATION message (see Section 2.2/2.3,
respectively). respectively).
<BEGIN NOTE for explanation. To be removed before publication as
an RFC>
With this additional note, the generic processing to achieve
interworking between SONET and SDH (as originally specified in RFC
3946) is explicitly provided for STS-3c SPE and VC-4 signals.
<END NOTE>
o) Number of Virtual Components (NVC): 16 bits o) Number of Virtual Components (NVC): 16 bits
This field indicates the number of signals that are requested to This field indicates the number of signals that are requested to
be virtually concatenated. These signals are all of the same type be virtually concatenated. These signals are all of the same type
E.Mannie & D.Papadimitriou (Editors) 6
by definition. They are Elementary Signal SPEs/VCs for which by definition. They are Elementary Signal SPEs/VCs for which
signal types are defined in this document, i.e., VT1.5_SPE/VC-11, signal types are defined in this document, i.e., VT1.5_SPE/VC-11,
VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS- VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS-
3c_SPE/VC-4. 3c_SPE/VC-4.
This field is set to 0 (default value) to indicate that no virtual This field is set to 0 (default value) to indicate that no virtual
concatenation is requested. concatenation is requested.
o) Multiplier (MT): 16 bits o) 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 identical signals can be either identical Elementary Signals, or identical
contiguously concatenated signals, or identical virtually contiguously concatenated signals, or identical virtually
concatenated signals. Note that all these signals belong thus to concatenated signals. Note that all these signals belong thus to
the same LSP. the same LSP.
E.Mannie & D.Papadimitriou (Editors) 6
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 are concatenated signals is done via the order of the labels that are
specified in the signaling. The first set of labels must describe specified in the signaling. The first set of labels must describe
the first component (set of individual signals belonging to the the first component (set of individual signals belonging to the
first virtual concatenated signal), the second set must describe first virtual concatenated signal), the second set must describe
the second component (set of individual signals belonging to the the second component (set of individual signals belonging to the
second virtual concatenated signal) and so on. second virtual concatenated signal) and so on.
This field is set to one (default value) to indicate that exactly This field is set to one (default value) to indicate that exactly
one instance of a signal is being requested. Intermediate and one instance of a signal is being requested. Intermediate and
skipping to change at line 383 skipping to change at line 364
provide different types of transparency. Not all combinations are provide different types of transparency. Not all combinations are
necessarily valid. The default value for this field is zero, i.e., necessarily valid. The default value for this field is zero, i.e.,
no transparency requested. no transparency requested.
Transparency, as defined from the point of view of this signaling Transparency, as defined from the point of view of this signaling
specification, is only applicable to the fields in the SONET/SDH specification, is only applicable to the fields in the SONET/SDH
frame overheads. In the SONET case, these are the fields in the frame overheads. In the SONET case, these are the fields in the
Section Overhead (SOH), and the Line Overhead (LOH). In the SDH Section Overhead (SOH), and the Line Overhead (LOH). In the SDH
case, these are the fields in the Regenerator Section Overhead case, these are the fields in the Regenerator Section Overhead
(RSOH), the Multiplex Section overhead (MSOH), and the pointer (RSOH), the Multiplex Section overhead (MSOH), and the pointer
E.Mannie & D.Papadimitriou (Editors) 7
fields between the two. With SONET, the pointer fields are part of fields between the two. With SONET, the pointer fields are part of
the LOH. the LOH.
Note as well that transparency is only applicable when using the Note as well that transparency is only applicable when using the
following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4,
STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one
transparency type must be specified when requesting such a signal transparency type must be specified when requesting such a signal
type. type.
Transparency indicates precisely which fields in these overheads Transparency indicates precisely which fields in these overheads
must be delivered unmodified at the other end of the LSP. An must be delivered unmodified at the other end of the LSP. An
ingress LSR requesting transparency will pass these overhead ingress LSR requesting transparency will pass these overhead
fields that must be delivered to the egress LSR without any fields that must be delivered to the egress LSR without any
change. From the ingress and egress LSRs point of views, these change. From the ingress and egress LSRs point of views, these
fields must be seen as unmodified. fields must be seen as unmodified.
E.Mannie & D.Papadimitriou (Editors) 7
Transparency is not applied at the interfaces with the initiating Transparency is not applied at the interfaces with the initiating
and terminating LSRs, but is only applied between intermediate and terminating LSRs, but is only applied between intermediate
LSRs. The transparency field is used to request an LSP that LSRs. The transparency field is used to request an LSP that
supports the requested transparency type; it may also be used to supports the requested transparency type; it may also be used to
setup the transparency process to be applied at each intermediate setup the transparency process to be applied at each intermediate
LSR. LSR.
The different transparency flags are the following: The different transparency flags are the following:
Flag 1 (bit 1): Section/Regenerator Section layer. Flag 1 (bit 1): Section/Regenerator Section layer.
skipping to change at line 439 skipping to change at line 419
Line/Multiplex Section layer transparency means that the LOH/MSOH Line/Multiplex Section layer transparency means that the LOH/MSOH
must be delivered unmodified. This implies that pointers cannot be must be delivered unmodified. This implies that pointers cannot be
adjusted. adjusted.
o) Profile (P): 32 bits o) Profile (P): 32 bits
This field is intended to indicate particular capabilities that This field is intended to indicate particular capabilities that
must be supported for the LSP, for example monitoring must be supported for the LSP, for example monitoring
capabilities. capabilities.
E.Mannie & D.Papadimitriou (Editors) 8
No standard profile is currently defined and this field SHOULD be No standard profile is currently defined and this field SHOULD be
set to zero when transmitted and SHOULD be ignored when received. set to zero when transmitted and SHOULD be ignored when received.
In the future TLV based extensions may be created. 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
content 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 for SONET ANSI T1.105 objects have the following class and type for SONET ANSI T1.105
and SDH ITU-T G.707: and SDH ITU-T G.707:
SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4
SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4
E.Mannie & D.Papadimitriou (Editors) 8
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
skipping to change at line 495 skipping to change at line 475
generate a PathErr message with a "Traffic Control Error/Service generate a PathErr message with a "Traffic Control Error/Service
unsupported" indication (see [RFC2205]). unsupported" indication (see [RFC2205]).
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 content 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:
E.Mannie & D.Papadimitriou (Editors) 9
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: The type field for the SONET/SDH Traffic Parameters TLV is:
0x0838. 0x0838.
Intermediate and egress nodes MUST verify that the node itself and Intermediate and egress nodes MUST verify that the node itself and
the interfaces on which the LSP will be established can support the interfaces on which the LSP will be established can support
the requested Signal Type, RCC, NCC, NVC and Multiplier (as the requested Signal Type, RCC, NCC, NVC and Multiplier (as
defined in Section 2.1). If the requested value(s) can not be defined in Section 2.1). If the requested value(s) can not be
supported, the receiver node MUST generate a NOTIFICATION message supported, the receiver node MUST generate a NOTIFICATION message
with a "Resource Unavailable" status code (see [RFC3212]). with a "Resource Unavailable" status code (see [RFC3212]).
E.Mannie & D.Papadimitriou (Editors) 9
In addition, if the MT field is received with a zero value, the In addition, if the MT field is received with a zero value, the
node MUST generate a NOTIFICATION message with a "Resource node MUST generate a NOTIFICATION message with a "Resource
Unavailable" status code (see [RFC3212]). Unavailable" status code (see [RFC3212]).
Intermediate nodes MUST also verify that the node itself and the Intermediate nodes MUST also verify that the node itself and the
interfaces on which the LSP will be established can support the interfaces on which the LSP will be established can support the
requested Transparency (as defined in Section 2.1). If the requested Transparency (as defined in Section 2.1). If the
requested value(s) can not be supported, the receiver node MUST requested value(s) can not be supported, the receiver node MUST
generate a NOTIFICATION message with a "Resource Unavailable" generate a NOTIFICATION message with a "Resource Unavailable"
status code (see [RFC3212]). status code (see [RFC3212]).
skipping to change at line 550 skipping to change at line 530
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. The same format of create unique multiplex entry names or labels. The same format of
label is used for SONET and SDH. As explained in [RFC3471], a label is used for SONET and SDH. As explained in [RFC3471], a
label does not identify the "class" to which the label belongs. label does not identify the "class" to which the label belongs.
This is implicitly determined by the link on which the label is This is implicitly determined by the link on which the label is
used. used.
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.
E.Mannie & D.Papadimitriou (Editors) 10
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 unique label is encoded as a single 32 bit label Label field. This unique label is encoded as a single 32 bit label
value (as defined in this Section) of the Generalized Label object value (as defined in this Section) of the Generalized Label object
(Class-Num = 16, C-Type = 2)/TLV (0x0825). This label identifies (Class-Num = 16, C-Type = 2)/TLV (0x0825). This label identifies
the lowest time-slot occupied by the contiguously concatenated the lowest time-slot occupied by the contiguously concatenated
signal. By lowest time-slot we mean the one having the lowest signal. By lowest time-slot we mean the one having the lowest
label (value) when compared as integer values, i.e., the time-slot label (value) when compared as integer values, i.e., the time-slot
occupied by the first component signal of the concatenated signal occupied by the first component signal of the concatenated signal
encountered when descending the tree. 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. This ordered list of labels labels in the concatenation is given. This ordered list of labels
is encoded as a sequence of 32 bit label values (as defined in is encoded as a sequence of 32 bit label values (as defined in
this Section) of the Generalized Label object (Class-Num = 16, C- this Section) of the Generalized Label object (Class-Num = 16, C-
Type = 2)/TLV (0x0825). Each label indicates the first time-slot Type = 2)/TLV (0x0825). Each label indicates the first time-slot
E.Mannie & D.Papadimitriou (Editors) 10
occupied by a component of the virtually concatenated signal. The occupied by a component of the virtually concatenated signal. The
order of the labels must reflect the order of the payloads to order of the labels must reflect the order of the payloads to
concatenate (not the physical order of time-slots). The above concatenate (not the physical order of time-slots). The above
representation limits virtual concatenation to remain within a representation limits virtual concatenation to remain within a
single (component) link; it imposes as such a restriction compared single (component) link; it imposes as such a restriction compared
to the ANSI [T1.105]/ ITU-T [G.707] recommendations. The standard to the ANSI [T1.105]/ ITU-T [G.707] recommendations. The standard
definition for virtual concatenation allows each virtual definition for virtual concatenation allows each virtual
concatenation components to travel over diverse paths. Within concatenation components to travel over diverse paths. Within
GMPLS, virtual concatenation components must travel over the same GMPLS, virtual concatenation components must travel over the same
(component) link if they are part of the same LSP. This is due to (component) link if they are part of the same LSP. This is due to
skipping to change at line 597 skipping to change at line 578
the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV
(0x0825). In case of multiplication of virtually concatenated (0x0825). In case of multiplication of virtually concatenated
signals, the explicit ordered list of set of labels that take part signals, the explicit ordered list of set of labels that take part
in the Final Signal is given. The first set of labels indicates in the Final Signal is given. The first set of labels indicates
the time-slots occupied by the first virtually concatenated the time-slots occupied by the first virtually concatenated
signal, the second set of labels indicates the time-slots occupied signal, the second set of labels indicates the time-slots occupied
by the second virtually concatenated signal, and so on. The above by the second virtually concatenated signal, and so on. The above
representation limits multiplication to remain within a single representation limits multiplication to remain within a single
(component) link. (component) link.
<BEGIN NOTE for explanation. To be removed before publication as
an RFC>
Clarification of label encoding added in each of the three
paragraphs above.
<END NOTE>
E.Mannie & D.Papadimitriou (Editors) 11
The format of the label for SONET and/or SDH TDM-LSR link is: The format of the label for SONET and/or SDH 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is an extension of the numbering scheme defined in [G.707] This is an extension of the numbering scheme defined in [G.707]
sections 7.3.7 to 7.3.13, i.e., the (K, L, M) numbering. Note sections 7.3.7 to 7.3.13, i.e., the (K, L, M) numbering. Note
skipping to change at line 629 skipping to change at line 601
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.
E.Mannie & D.Papadimitriou (Editors) 11
When a hierarchy of SONET/SDH LSPs is used, a higher order LSP When a hierarchy of SONET/SDH LSPs is used, a higher order LSP
with a given bandwidth can be used to carry lower order LSPs. with a given bandwidth can be used to carry lower order LSPs.
Remember here that a higher order LSP is established through a Remember here that a higher order LSP is established through a
SONET/SDH higher order path layer network and a lower order LSP, SONET/SDH higher order path layer network and a lower order LSP,
through a SONET/SDH lower order path layer network (see also ITU-T through a SONET/SDH lower order path layer network (see also ITU-T
G.803, Section 3 for the corresponding definitions). In this G.803, Section 3 for the corresponding definitions). In this
context, the higher order SONET/SDH LSP behaves as a "virtual context, the higher order SONET/SDH LSP behaves as a "virtual
link" with a given bandwidth (e.g., VC-3), it may also be used as link" with a given bandwidth (e.g., VC-3), it may also be used as
a Forwarding Adjacency. A lower order SONET/SDH LSP can be a Forwarding Adjacency. A lower order SONET/SDH LSP can be
established through that higher order LSP. Since a label is local established through that higher order LSP. Since a label is local
skipping to change at line 659 skipping to change at line 632
i.e., non-significant, while L and M will be used to indicate the i.e., non-significant, while L and M will be used to indicate the
signal allocated in that VC-3. signal allocated in that VC-3.
In case of tunneling such as VC-4 containing VC-3 containing In case of tunneling such as VC-4 containing VC-3 containing
VC-12/VC-11 where the SUKLM structure is not adequate to represent VC-12/VC-11 where the SUKLM structure is not adequate to represent
the full signal structure, a hierarchical approach must be used, the full signal structure, a hierarchical approach must be used,
i.e., per layer network signaling. i.e., per layer network signaling.
The possible values of S, U, K, L and M are defined as follows: The possible values of S, U, K, L and M are defined as follows:
E.Mannie & D.Papadimitriou (Editors) 12
1. S=1->N is the index of a particular STS-3/AUG-1 inside an 1. S=1->N is the index of a particular STS-3/AUG-1 inside an
STS-N/STM-N multiplex. S is only significant for SONET STS-N STS-N/STM-N multiplex. S is only significant for SONET STS-N
(N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1
and STM-0. and STM-0.
2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an 2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an
STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and
SDH STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0. SDH STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0.
3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is 3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is
skipping to change at line 685 skipping to change at line 657
cases. cases.
5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12 5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12
or VT3_SPE within a VT_Group/TUG-2. M=1->2 indicates a specific or VT3_SPE within a VT_Group/TUG-2. M=1->2 indicates a specific
VT3 SPE inside the corresponding VT Group, these values MUST VT3 SPE inside the corresponding VT Group, these values MUST
NOT be used for SDH since there is no equivalent of VT3 with NOT be used for SDH since there is no equivalent of VT3 with
SDH. M=3->5 indicates a specific VT2_SPE/VC-12 inside the SDH. M=3->5 indicates a specific VT2_SPE/VC-12 inside the
corresponding VT_Group/TUG-2. M=6->9 indicates a specific corresponding VT_Group/TUG-2. M=6->9 indicates a specific
VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2. VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2.
E.Mannie & D.Papadimitriou (Editors) 12
Note that a label always has to be interpreted according the Note that a label always has to be interpreted according the
SONET/SDH traffic parameters, i.e., a label by itself does not SONET/SDH traffic parameters, i.e., a label by itself does not
allow knowing which signal is being requested (a label is context allow knowing which signal is being requested (a label is context
sensitive). sensitive).
The label format defined in this section, referred to as SUKLM, The label format defined in this section, referred to as SUKLM,
MUST be used for any SONET/SDH signal requests that are not MUST be used for any SONET/SDH signal requests that are not
transparent i.e., when all Transparency (T) bits defined in transparent i.e., when all Transparency (T) bits defined in
section 2.1 are set to zero. Any transparent STS-1/STM-0/STS- section 2.1 are set to zero. Any transparent STS-1/STM-0/STS-
3*N/STM-N (N=1, 4, 16, 64, 256) signal request MUST use a label 3*N/STM-N (N=1, 4, 16, 64, 256) signal request MUST use a label
skipping to change at line 714 skipping to change at line 687
3 3rd AUG-1 3rd STS-3 3 3rd AUG-1 3rd STS-3
4 4rd AUG-1 4rd STS-3 4 4rd AUG-1 4rd STS-3
: : : : : :
N Nth AUG-1 Nth STS-3 N Nth AUG-1 Nth STS-3
The U encoding is summarized in the following table: The U encoding is summarized in the following table:
U SDH AUG-1 SONET STS-3 U SDH AUG-1 SONET STS-3
------------------------------------------------- -------------------------------------------------
0 other other 0 other other
E.Mannie & D.Papadimitriou (Editors) 13
1 1st VC-3 1st STS-1 SPE 1 1st VC-3 1st STS-1 SPE
2 2nd VC-3 2nd STS-1 SPE 2 2nd VC-3 2nd STS-1 SPE
3 3rd VC-3 3rd STS-1 SPE 3 3rd VC-3 3rd STS-1 SPE
The K encoding is summarized in the following table: The K encoding is summarized in the following table:
K SDH VC-4 K SDH VC-4
--------------- ---------------
0 other 0 other
1 1st TUG-3 1 1st TUG-3
skipping to change at line 740 skipping to change at line 711
L SDH TUG-3 SDH VC-3 SONET STS-1 SPE L SDH TUG-3 SDH VC-3 SONET STS-1 SPE
------------------------------------------------- -------------------------------------------------
0 other other other 0 other other other
1 1st TUG-2 1st TUG-2 1st VTG 1 1st TUG-2 1st TUG-2 1st VTG
2 2nd TUG-2 2nd TUG-2 2nd VTG 2 2nd TUG-2 2nd TUG-2 2nd VTG
3 3rd TUG-2 3rd TUG-2 3rd VTG 3 3rd TUG-2 3rd TUG-2 3rd VTG
4 4th TUG-2 4th TUG-2 4th VTG 4 4th TUG-2 4th TUG-2 4th VTG
5 5th TUG-2 5th TUG-2 5th VTG 5 5th TUG-2 5th TUG-2 5th VTG
6 6th TUG-2 6th TUG-2 6th VTG 6 6th TUG-2 6th TUG-2 6th VTG
E.Mannie & D.Papadimitriou (Editors) 13
7 7th TUG-2 7th TUG-2 7th 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 TUG-2 SONET VTG M SDH TUG-2 SONET VTG
------------------------------------------------- -------------------------------------------------
0 other other 0 other other
1 - 1st VT3 SPE 1 - 1st VT3 SPE
2 - 2nd VT3 SPE 2 - 2nd VT3 SPE
3 1st VC-12 1st VT2 SPE 3 1st VC-12 1st VT2 SPE
skipping to change at line 770 skipping to change at line 743
1 is: S>0, U=0, K=0, L=0, M=0. 1 is: S>0, U=0, K=0, L=0, M=0.
Example 2: the label for the VC-3 within the Kth-1 TUG-3 within Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0. the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth
STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0. STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.
Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2 Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2
in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1
E.Mannie & D.Papadimitriou (Editors) 14
is: S>0, U>0, K=0, L>0, M=0. is: S>0, U>0, K=0, L>0, M=0.
Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT
Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the
Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8. Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.
Example 6: the label for the STS-12c SPE/VC-4-4c which uses the Example 6: the label for the STS-12c SPE/VC-4-4c which uses the
9th STS-3/AUG-1 as its first timeslot is: S=9, U=0, 9th STS-3/AUG-1 as its first timeslot is: S=9, U=0,
K=0, L=0, M=0. K=0, L=0, M=0.
skipping to change at line 795 skipping to change at line 766
signal starts and the lowest part is not significant. signal starts and the lowest part is not significant.
In case of STM-0/STS-1, the values of S, U and K must be equal to In case of STM-0/STS-1, the values of S, U and K must be equal to
zero according to the field coding rules. For instance, when zero according to the field coding rules. For instance, when
requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0, 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 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. S=0, U=0, K=0, L>0, M=6..9.
Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS- Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS-
3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM 3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM
E.Mannie & D.Papadimitriou (Editors) 14
label format and encoding is not applicable and the label encoding label format and encoding is not applicable and the label encoding
MUST follow the rules defined in [RFC3471] Section 3.2. MUST follow the rules defined in [RFC3471] Section 3.2.
4. Acknowledgments 4. Acknowledgments
Valuable comments and input were received from the CCAMP mailing Valuable comments and input were received from the CCAMP mailing
list where outstanding discussions took place. list where outstanding discussions took place.
The authors would like to thank Richard Rabbat for its valuable The authors would like to thank Richard Rabbat for its valuable
input that lead to this revision. input that lead to this revision.
skipping to change at line 826 skipping to change at line 799
Two RSVP C-Types in registry: Two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/rsvp-parameters
- A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see - A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see
Section 2.2). Section 2.2).
- A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see - A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see
Section 2.2). Section 2.2).
E.Mannie & D.Papadimitriou (Editors) 15
One LDP TLV Type in registry: One LDP TLV Type in registry:
http://www.iana.org/assignments/ldp-namespaces http://www.iana.org/assignments/ldp-namespaces
- A type field for the SONET/SDH Traffic Parameters TLV (see - A type field for the SONET/SDH Traffic Parameters TLV (see
Section 2.3). Section 2.3).
7. References 7. References
7.1 Normative References 7.1 Normative References
skipping to change at line 850 skipping to change at line 822
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997. 1 Functional Specification", RFC 2205, September 1997.
[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.
E.Mannie & D.Papadimitriou (Editors) 15
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N., Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J., Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T., and A. Malis, "Constraint-Based LSP Setup Kilty, T., and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002. using LDP", RFC 3212, January 2002.
skipping to change at line 884 skipping to change at line 857
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label
Switching (GMPLS) Architecture", RFC 3945, October Switching (GMPLS) Architecture", RFC 3945, October
2004. 2004.
[T1.105] "Synchronous Optical Network (SONET): Basic [T1.105] "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and Description Including Multiplex Structure, Rates, and
Formats", ANSI T1.105, October 2000. Formats", ANSI T1.105, October 2000.
E.Mannie & D.Papadimitriou (Editors) 16 E.Mannie & D.Papadimitriou (Editors) 16
E.Mannie & D.Papadimitriou (Editors) 17
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"
According to the ITU-T [G.707] recommendation a VC-3 in the TU- According to the ITU-T [G.707] recommendation a VC-3 in the TU-
skipping to change at line 924 skipping to change at line 895
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 AU-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 & D.Papadimitriou (Editors) 18 E.Mannie & D.Papadimitriou (Editors) 17
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 980 skipping to change at line 951
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 1 (standard contiguous concatenation), NCC with value 1, value 1 (standard contiguous concatenation), NCC with value 1,
NVC with value 0, MT with value 1 and T with value 0 to an STS- NVC with value 0, MT with value 1 and T with value 0 to an STS-
3c SPE Elementary Signal. 3c SPE 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
value 1 (standard contiguous concatenation), NCC with value 16, value 1 (standard contiguous concatenation), NCC with value 16,
NVC with value 0, MT with value 1 and T with value 0 to an STS- NVC with value 0, MT with value 1 and T with value 0 to an STS-
3c SPE Elementary Signal. 3c SPE Elementary Signal.
E.Mannie & D.Papadimitriou (Editors) 19 E.Mannie & D.Papadimitriou (Editors) 18
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 1, NCC with value 1, NVC with value 9 (virtual with value 1, NCC with value 1, NVC with value 9 (virtual
concatenation of 9 STS-3c), MT with value 1 and T with value 0 concatenation of 9 STS-3c), MT with value 1 and T with value 0
to an STS-3c SPE Elementary Signal. to an STS-3c SPE Elementary Signal.
skipping to change at line 1037 skipping to change at line 1008
Contributors are listed by alphabetical order: Contributors are listed by alphabetical order:
Stefan Ansorge (Alcatel) Stefan Ansorge (Alcatel)
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart, Germany 70435 Stuttgart, Germany
EMail: stefan.ansorge@alcatel.de EMail: stefan.ansorge@alcatel.de
Peter Ashwood-Smith (Nortel) Peter Ashwood-Smith (Nortel)
PO. Box 3511 Station C, PO. Box 3511 Station C,
E.Mannie & D.Papadimitriou (Editors) 20 E.Mannie & D.Papadimitriou (Editors) 19
Ottawa, ON K1Y 4H7, Canada Ottawa, ON K1Y 4H7, Canada
EMail:petera@nortelnetworks.com EMail:petera@nortelnetworks.com
Ayan Banerjee (Calient) Ayan Banerjee (Calient)
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138, USA San Jose, CA 95138, USA
EMail: abanerjee@calient.net EMail: abanerjee@calient.net
Lou Berger (Movaz) Lou Berger (Movaz)
7926 Jones Branch Drive 7926 Jones Branch Drive
skipping to change at line 1093 skipping to change at line 1064
D-81379 Munich, Germany D-81379 Munich, Germany
EMail: juergen.heiles@siemens.com EMail: juergen.heiles@siemens.com
Suresh Katukam (Cisco) Suresh Katukam (Cisco)
1450 N. McDowell Blvd, 1450 N. McDowell Blvd,
Petaluma, CA 94954-6515, USA Petaluma, CA 94954-6515, USA
EMail: suresh.katukam@cisco.com EMail: suresh.katukam@cisco.com
Kireeti Kompella (Juniper) Kireeti Kompella (Juniper)
E.Mannie & D.Papadimitriou (Editors) 21 E.Mannie & D.Papadimitriou (Editors) 20
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
EMail: kireeti@juniper.net EMail: kireeti@juniper.net
Jonathan P. Lang (Calient) Jonathan P. Lang (Calient)
25 Castilian 25 Castilian
Goleta, CA 93117, USA Goleta, CA 93117, USA
EMail: jplang@calient.net EMail: jplang@calient.net
Fong Liaw (Solas Research) Fong Liaw (Solas Research)
skipping to change at line 1148 skipping to change at line 1119
Vishal Sharma (Metanoia) Vishal Sharma (Metanoia)
335 Elan Village Lane 335 Elan Village Lane
San Jose, CA 95134, USA San Jose, CA 95134, USA
EMail: vsharma87@yahoo.com EMail: vsharma87@yahoo.com
George Swallow (Cisco) George Swallow (Cisco)
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824, USA Chelmsford, MA 01824, USA
EMail: swallow@cisco.com EMail: swallow@cisco.com
E.Mannie & D.Papadimitriou (Editors) 22 E.Mannie & D.Papadimitriou (Editors) 21
Z. Bo Tang (Tellium) Z. Bo Tang (Tellium)
2 Crescent Place, P.O. Box 901 2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA Oceanport, NJ 07757-0901, USA
EMail: btang@tellium.com EMail: btang@tellium.com
Eve Varma (Lucent) Eve Varma (Lucent)
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733-3030, USA Holmdel, NJ 07733-3030, USA
EMail: evarma@lucent.com EMail: evarma@lucent.com
skipping to change at line 1181 skipping to change at line 1152
EMail: eric_mannie@hotmail.com EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (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
E.Mannie & D.Papadimitriou (Editors) 23 E.Mannie & D.Papadimitriou (Editors) 22
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
skipping to change at line 1229 skipping to change at line 1200
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
E.Mannie & D.Papadimitriou (Editors) 24 E.Mannie & D.Papadimitriou (Editors) 23
 End of changes. 33 change blocks. 
56 lines changed or deleted 27 lines changed or added

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