diff options
Diffstat (limited to 'doc/rfc/rfc4606.txt')
| -rw-r--r-- | doc/rfc/rfc4606.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4606.txt b/doc/rfc/rfc4606.txt new file mode 100644 index 0000000..d6a40a9 --- /dev/null +++ b/doc/rfc/rfc4606.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group E. Mannie +Request for Comments: 4606 Perceval +Obsoletes: 3946 D. Papadimitriou +Category: Standards Track Alcatel + August 2006 + + + Generalized Multi-Protocol Label Switching (GMPLS) Extensions for + Synchronous Optical Network (SONET) and + Synchronous Digital Hierarchy (SDH) Control + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution cof this memo is + unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document provides minor clarification to RFC 3946. + + This document is a companion to the Generalized Multi-protocol Label + Switching (GMPLS) signaling. It defines the Synchronous Optical + Network (SONET)/Synchronous Digital Hierarchy (SDH) technology- + specific information needed when GMPLS signaling is used. + +Table of Contents + + 1. Introduction ....................................................2 + 2. SONET and SDH Traffic Parameters ................................3 + 2.1. SONET/SDH Traffic Parameters ...............................3 + 2.2. RSVP-TE Details ............................................9 + 2.3. CR-LDP Details ............................................10 + 3. SONET and SDH Labels ...........................................11 + 4. Acknowledgements ...............................................16 + 5. Security Considerations ........................................16 + 6. IANA Considerations ............................................16 + Contributors ......................................................17 + Appendix 1. Signal Type Values Extension for VC-3 .................20 + Annex 1. Examples .................................................20 + Normative References ..............................................23 + + + +Mannie & Papadimitriou Standards Track [Page 1] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +1. Introduction + + As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from + supporting packet (Packet Switching Capable, or PSC) interfaces and + switching to include support of four new classes of interfaces and + switching: Layer-2 Switch Capable (L2SC), Time-Division Multiplex + (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A + functional description of the extensions to MPLS signaling needed to + support the new classes of interfaces and switching is provided in + [RFC3471]. [RFC3473] describes RSVP-TE-specific formats and + mechanisms needed to support all five classes of interfaces, and CR- + LDP extensions can be found in [RFC3472]. + + This document presents details that are specific to Synchronous + Optical Network (SONET)/Synchronous Digital Hierarchy (SDH). Per + [RFC3471], SONET/SDH-specific parameters are carried in the signaling + protocol in traffic parameter specific objects. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Moreover, the reader is assumed to be familiar with the terminology + in American National Standards Institute (ANSI) [T1.105] and ITU-T + [G.707], as well as with that in [RFC3471], [RFC3472], and [RFC3473]. + The following abbreviations are used in this document: + + DCC: Data Communications Channel. + LOVC: Lower-Order Virtual Container + HOVC: Higher-Order Virtual Container + MS: Multiplex Section. + MSOH: Multiplex Section overhead. + POH: Path overhead. + RS: Regenerator Section. + RSOH: Regenerator Section overhead. + SDH: Synchronous digital hierarchy. + SOH: Section overhead. + SONET: Synchronous Optical Network. + SPE: Synchronous Payload Envelope. + STM(-N): Synchronous Transport Module (-N) (SDH). + STS(-N): Synchronous Transport Signal-Level N (SONET). + VC-n: Virtual Container-n (SDH). + VTn: Virtual Tributary-n (SONET). + + + + + + + + +Mannie & Papadimitriou Standards Track [Page 2] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +2. SONET and SDH Traffic Parameters + + This section defines the GMPLS traffic parameters for SONET/SDH. The + protocol-specific formats, for the SONET/SDH-specific RSVP-TE objects + and CR-LDP TLVs, are described in Sections 2.2 and 2.3, respectively. + + These traffic parameters specify a base set of capabilities for SONET + ANSI [T1.105] and SDH ITU-T [G.707], such as concatenation and + transparency. Other documents may further enhance this set of + capabilities in the future. For instance, signaling for SDH over PDH + ITU-T G.832 or sub-STM-0 ITU-T G.708 interfaces could be defined. + + The traffic parameters defined hereafter (see Section 2.1) MUST be + used when the label is encoded as SUKLM as defined in this memo (see + Section 3). They MUST also be used when requesting one of Section/RS + or Line/MS overhead transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4, + 16, 64, 256) signals. + + The traffic parameters and label encoding defined in [RFC3471], + Section 3.2, MUST be used for fully transparent STS-1/STM-0, + STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal requests. A fully + transparent signal is one for which all overhead is left unmodified + by intermediate nodes; i.e., when all defined Transparency (T) bits + would be set if the traffic parameters defined in Section 2.1 were + used. + +2.1. SONET/SDH Traffic Parameters + + The traffic parameters for SONET/SDH are organized as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signal Type | RCC | NCC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NVC | Multiplier (MT) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transparency (T) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Profile (P) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Annex 1 lists examples of SONET and SDH signal coding. + + + + + + + + +Mannie & Papadimitriou Standards Track [Page 3] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + o) Signal Type (ST): 8 bits + + This field indicates the type of Elementary Signal that constitutes + the requested Label Switched Path (LSP). Several transforms can be + applied successively on the Elementary Signal to build the Final + Signal actually being requested for the LSP. + + Each transform application is optional and must be ignored if zero, + except the Multiplier (MT), which cannot be zero and is ignored if + equal to one. + + Transforms must be applied strictly in the following order: + + - First, contiguous concatenation (by using the RCC and NCC fields) + can be optionally applied on the Elementary Signal, resulting in a + contiguously concatenated signal. + + - Second, virtual concatenation (by using the NVC field) can be + optionally applied on the Elementary Signal, resulting in a + virtually concatenated signal. + + - Third, some transparency (by using the Transparency field) can be + optionally specified when a frame is requested as signal rather + than an SPE- or VC-based signal. + + - Fourth, a multiplication (by using the Multiplier field) can be + optionally applied directly on the Elementary Signal, on the + contiguously concatenated signal obtained from the first phase, on + the virtually concatenated signal obtained from the second phase, + or on these signals combined with some transparency. + + Permitted Signal Type values for SONET/SDH are + + Value Type (Elementary Signal) + ----- ------------------------ + 1 VT1.5 SPE / VC-11 + 2 VT2 SPE / VC-12 + 3 VT3 SPE + 4 VT6 SPE / VC-2 + 5 STS-1 SPE / VC-3 + 6 STS-3c SPE / VC-4 + 7 STS-1 / STM-0 (only when transparency is requested) + 8 STS-3 / STM-1 (only when transparency is requested) + 9 STS-12 / STM-4 (only when transparency is requested) + 10 STS-48 / STM-16 (only when transparency is requested) + 11 STS-192 / STM-64 (only when transparency is requested) + 12 STS-768 / STM-256 (only when transparency is requested) + + + + +Mannie & Papadimitriou Standards Track [Page 4] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + A dedicated signal type is assigned to a SONET STS-3c SPE instead of + being coded as a contiguous concatenation of three STS-1 SPEs. This + is done in order to provide easy interworking between SONET and SDH + signaling. + + Appendix 1 adds one signal type (optional) to the above values. + + o) Requested Contiguous Concatenation (RCC): 8 bits + + This field is used to request the optional SONET/SDH contiguous + concatenation of the Elementary Signal. + + This field is a vector of flags. Each flag indicates the support of + a particular type of contiguous concatenation. Several flags can be + set at the same time to indicate a choice. + + These flags allow an upstream node to indicate to a downstream node + the different types of contiguous concatenation that it supports. + However, the downstream node decides which one to use according to + its own rules. + + A downstream node receiving simultaneously more than one flag chooses + a particular type of contiguous concatenation, if any is supported, + and according to criteria that are out of this document's scope. A + downstream node that doesn't support any of the concatenation types + indicated by the field must refuse the LSP request. In particular, + it must refuse the LSP request if it doesn't support contiguous + concatenation at all. + + When several flags have been set, the upstream node retrieves the + (single) type of contiguous concatenation the downstream node has + selected by looking at the position indicated by the first label and + the number of labels as returned by the downstream node (see also + Section 3). + + The entire field is set to zero to indicate that no contiguous + concatenation is requested at all (default value). A non-zero field + indicates that some contiguous concatenation is requested. + + The following flag is defined: + + Flag 1 (bit 1): Standard contiguous concatenation. + + Flag 1 indicates that the standard SONET/SDH contiguous + concatenation, as defined in [T1.105]/[G.707], is supported. Note + that bit 1 is the low-order bit. Other flags are reserved for + extensions; if not used, they must be set to zero when sent and + should be ignored when received. + + + +Mannie & Papadimitriou Standards Track [Page 5] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + See note 1 in the section on the NCC about the SONET contiguous + concatenation of STS-1 SPEs when the number of components is a + multiple of three. + + o) Number of Contiguous Components (NCC): 16 bits + + This field indicates the number of identical SONET SPEs/SDH VCs + (i.e., Elementary Signal) that are requested to be concatenated, as + specified in the RCC field. + + Note 1: When a SONET STS-Nc SPE with N=3*X is requested, the + Elementary Signal to be used must always be an STS-3c_SPE signal + type, and the value of NCC must always be equal to X. This allows + facilitating the interworking between SONET and SDH. In particular, + it means that the contiguous concatenation of three STS-1 SPEs cannot + be requested, as according to this specification this type of signal + must be coded using the STS-3c SPE signal type. + + Note 2: When a transparent STS-N/STM-N signal is requested that is + limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the + signal type must be STS-N/STM-N, RCC with flag 1, NCC set to 1. + + The NCC value must be consistent with the type of contiguous + concatenation being requested in the RCC field. In particular, this + field is irrelevant if no contiguous concatenation is requested (RCC + = 0). In that case, it must be set to zero when sent and should be + ignored when received. A RCC value different from 0 implies a number + of contiguous components greater than or equal to 1. + + Note 3: Following these rules, when a VC-4 signal is requested, the + 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, if + local conditions allow, since the setting of the RCC and NCC values + is locally driven, the requesting upstream node MAY set the RCC and + NCC values to either SDH or SONET settings without impacting the + function. Moreover, the downstream node SHOULD accept the requested + values if local conditions allow. If these values cannot be + supported, the receiver downstream node SHOULD generate a + PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, + respectively). + + o) Number of Virtual Components (NVC): 16 bits + + This field indicates the number of signals that are requested to be + virtually concatenated. These signals are all of the same type by + definition. They are Elementary Signal SPEs/VCs for which signal + types are defined in this document; i.e., VT1.5_SPE/VC-11, + + + + +Mannie & Papadimitriou Standards Track [Page 6] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3, or + STS-3c_SPE/VC-4. + + This field is set to 0 (default value) to indicate that no virtual + concatenation is requested. + + o) Multiplier (MT): 16 bits + + This field indicates the number of identical signals that are + requested for the LSP; i.e., that form the Final Signal. These + signals can be identical Elementary Signals, identical contiguously + concatenated signals, or identical virtually concatenated signals. + Note that all of these signals thus belong to the same LSP. + + The distinction between the components of multiple virtually + concatenated signals is done via the order of the labels that are + specified in the signaling. The first set of labels must describe + the first component (set of individual signals belonging to the first + virtual concatenated signal), the second set must describe the second + component (set of individual signals belonging to the second virtual + concatenated signal), and so on. + + This field is set to one (default value) to indicate that exactly one + instance of a signal is being requested. Intermediate and egress + nodes MUST verify that the node itself and the interfaces on which + the LSP will be established can support the requested multiplier + value. If the requested values cannot be supported, the receiver + node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 + and 2.3, respectively). + + Zero is an invalid value. If a zero is received, the node MUST + generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, + respectively). + + Note 1: When a transparent STS-N/STM-N signal is requested that is + limited to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the + multiplier field MUST be equal to 1 (only valid value). + + o) Transparency (T): 32 bits + + This field is a vector of flags that indicates the type of + transparency being requested. Several flags can be combined to + provide different types of transparency. Not all combinations are + necessarily valid. The default value for this field is zero, i.e., + no transparency is requested. + + + + + + +Mannie & Papadimitriou Standards Track [Page 7] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + Transparency, as defined from the point of view of this signaling + specification, is only applicable to the fields in the SONET/SDH + frame overheads. In the SONET case, these are the fields in the + Section Overhead (SOH) and the Line Overhead (LOH). In the SDH case, + these are the fields in the Regenerator Section Overhead (RSOH), the + Multiplex Section overhead (MSOH), and the pointer fields between the + two. With SONET, the pointer fields are part of the LOH. + + Note also that transparency is only applicable when the following + signal types are used: 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 + transparency type must be specified when such a signal type is + requested. + + Transparency indicates precisely which fields in these overheads must + be delivered unmodified at the other end of the LSP. An ingress + Label Switching Router (LSR) requesting transparency will pass these + overhead fields that must be delivered to the egress LSR without any + change. From the ingress and egress LSRs point of views, these + fields must be seen as being unmodified. + + Transparency is applied not at the interfaces with the initiating and + terminating LSRs but only between intermediate LSRs. The + transparency field is used to request an LSP that supports the + requested transparency type; it may also be used to set up the + transparency process to be applied at each intermediate LSR. + + The different transparency flags are as follows: + + Flag 1 (bit 1): Section/Regenerator Section layer + Flag 2 (bit 2): Line/Multiplex Section layer + + where bit 1 is the low-order bit. Other flags are reserved; they + should be set to zero when sent and ignored when received. A flag is + set to one to indicate that the corresponding transparency is + requested. + + Intermediate and egress nodes MUST verify that the node itself and + the interfaces on which the LSP will be established can support the + requested transparency. If the requested flags cannot be supported, + the receiver node MUST generate a PathErr/NOTIFICATION message (see + Sections 2.2 and 2.3, respectively). + + Section/Regenerator Section layer transparency means that the entire + frames must be delivered unmodified. This implies that pointers + cannot be adjusted. When Section/Regenerator Section layer + transparency is used all other flags MUST be ignored. + + + + +Mannie & Papadimitriou Standards Track [Page 8] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + Line/Multiplex Section layer transparency means that the LOH/MSOH + must be delivered unmodified. This implies that pointers cannot be + adjusted. + + o) Profile (P): 32 bits + + 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 ignored when received. + + In the future, TLV-based extensions may be created. + +2.2. RSVP-TE Details + + For RSVP-TE, the SONET/SDH traffic parameters are carried in the + SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is used + both for the SENDER_TSPEC object and for FLOWSPEC objects. 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 and SDH ITU-T + G.707: + + SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 + SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 + + There is no Adspec associated with the SONET/SDH SENDER_TSPEC. + Either the Adspec is omitted, or an int-serv Adspec with the Default + General Characterization Parameters and Guaranteed Service fragment + is used; see [RFC2210]. + + For a particular sender in a session, the contents of the FLOWSPEC + object received in a Resv message SHOULD be identical to the contents + of the SENDER_TSPEC object received in the corresponding Path + message. If the objects do not match, a ResvErr message with a + "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. + + Intermediate and egress nodes MUST verify that the node itself and + the interfaces on which the LSP will be established can support the + requested Signal Type, RCC, NCC, NVC and Multiplier (as defined in + Section 2.1). If the requested value(s) can not be supported, the + receiver node MUST generate a PathErr message with a "Traffic Control + Error/ Service unsupported" indication (see [RFC2205]). + + In addition, if the MT field is received with a zero value, the node + MUST generate a PathErr message with a "Traffic Control Error/Bad + Tspec value" indication (see [RFC2205]). + + + + +Mannie & Papadimitriou Standards Track [Page 9] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + Intermediate nodes MUST also verify that the node itself and the + interfaces on which the LSP will be established can support the + requested Transparency (as defined in Section 2.1). If the requested + value(s) cannot be supported, the receiver node MUST generate a + PathErr message with a "Traffic Control Error/Service unsupported" + indication (see [RFC2205]). + +2.3. CR-LDP Details + + For CR-LDP, the SONET/SDH traffic parameters are carried in the + SONET/SDH Traffic Parameters TLV. The content of the TLV is defined + above, in Section 2.1. The header of the TLV has the following + format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The type field for the SONET/SDH Traffic Parameters TLV is 0x0838. + + Intermediate and egress nodes MUST verify that the node itself and + the interfaces on which the LSP will be established can support the + requested Signal Type, RCC, NCC, NVC, and Multiplier (as defined in + Section 2.1). If the requested value(s) cannot be supported, the + receiver node MUST generate a NOTIFICATION message with a "Resource + Unavailable" status code (see [RFC3212]). + + In addition, if the MT field is received with a zero value, the node + MUST generate a NOTIFICATION message with a "Resource Unavailable" + status code (see [RFC3212]). + + Intermediate nodes MUST also verify that the node itself and the + interfaces on which the LSP will be established can support the + requested Transparency (as defined in Section 2.1). If the requested + value(s) cannot be supported, the receiver node MUST generate a + NOTIFICATION message with a "Resource Unavailable" status code (see + [RFC3212]). + + + + + + + + + + + + +Mannie & Papadimitriou Standards Track [Page 10] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +3. SONET and SDH Labels + + SONET and SDH each define a multiplexing structure. Both structures + are trees whose roots are, respectively, an STS-N or an STM-N and + whose leaves are the signals that can be transported via the time- + slots and switched between time-slots within an ingress port and + time-slots within an egress port; i.e., a VTx SPE, an STS-x SPE, or a + VC-x. A SONET/SDH label will identify the exact position (i.e., + first time-slot) of a particular VTx SPE, STS-x SPE, or VC-x signal + in a multiplexing structure. SONET and SDH labels are carried in the + Generalized Label per [RFC3473] and [RFC3472]. + + 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 create + unique multiplex entry names or labels. The same format of label is + used for SONET and SDH. As explained in [RFC3471], a label does not + identify the "class" to which the label belongs. This is implicitly + determined by the link on which the label is used. + + In case of signal concatenation or multiplication, a list of labels + can appear in the Label field of a Generalized Label. + + In case of contiguous concatenation, only one label appears in the + Label field. This unique label is encoded as a single 32-bit label + value (as defined in this section) of the Generalized Label object + (Class-Num = 16, C-Type = 2)/TLV (0x0825). This label identifies the + lowest time-slot occupied by the contiguously concatenated signal. + By lowest time-slot, we mean the one having the lowest label (value) + when compared as an integer value; i.e., the time-slot occupied by + the first component signal of the concatenated signal encountered + descending the tree. + + In case of virtual concatenation, the explicit ordered list of all + labels in the concatenation is given. This ordered list of labels is + encoded as a sequence of 32-bit label values (as defined in this + section) of the Generalized Label object (Class-Num = 16, C-Type = + 2)/TLV (0x0825). Each label indicates the first time-slot occupied + by a component of the virtually concatenated signal. The order of + the labels must reflect the order of the payloads to concatenate (not + the physical order of time-slots). The above representation limits + virtual concatenation to remain within a single (component) link; it + imposes, as such, a restriction compared to the ANSI [T1.105]/ ITU-T + [G.707] recommendations. The standard definition for virtual + concatenation allows each virtual concatenation components to travel + over diverse paths. Within GMPLS, virtual concatenation components + + + +Mannie & Papadimitriou Standards Track [Page 11] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + 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), the + explicit ordered list of all labels that take part in the Final + Signal is given. This ordered list of labels is encoded as a + sequence of 32-bit label values (as defined in this section) of the + Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825). + In case of multiplication of virtually concatenated signals, the + explicit ordered list of the set of labels that take part in the + Final Signal is given. The first set of labels indicates the time- + slots occupied by the first virtually concatenated signal, the second + set of labels indicates the time-slots occupied by the second + virtually concatenated signal, and so on. The above representation + limits multiplication to remain within a single (component) link. + + The format of the label for SONET and/or SDH TDM-LSR link is + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S | U | K | L | M | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This is an extension of the numbering scheme defined in [G.707], + Sections 7.3.7 through 7.3.13; i.e., the (K, L, M) numbering. Note + that the higher order numbering scheme defined in [G.707], Sections + 7.3.1 through 7.3.6, is not used here. + + Each letter indicates a possible branch number starting at the parent + node in the multiplex structure. Branches are considered as being + numbered in increasing order, starting from the top of the + multiplexing structure. The numbering starts at 1; zero is used to + indicate a non-significant or ignored field. + + When a field is not significant or ignored in a particular context, + it MUST be set to zero when transmitted and ignored when received. + + 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. Remember that + a higher-order LSP is established through a 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 G.803, Section 3, for the + + + +Mannie & Papadimitriou Standards Track [Page 12] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + corresponding definitions). In this 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 a Forwarding Adjacency. A + lower-order SONET/SDH LSP can be established through that higher- + order LSP. Since a label is local to a (virtual) link, the highest + part of that label (i.e., the S, U, and K fields) is non-significant + and is set to zero; i.e., the label is "0,0,0,L,M". Similarly, if + the structure of the lower-order LSP is unknown or not relevant, the + lowest part of that label (i.e., the L and M fields) is non- + significant and is set to zero; i.e., the label is "S,U,K,0,0". + + For instance, a VC-3 LSP can be used to carry lower-order LSPs. In + 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. + + 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 + the full signal structure, a hierarchical approach must be used; + i.e., per layer network signaling. + + The possible values of S, U, K, L, and M are defined as follows: + + 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 + (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and + STM-0. + + 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 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 + only significant for an SDH VC-4 structured in TUG-3s. K must be + 0 and ignored in all other cases. + + 4. L=1->7 is the index of a particular VT_Group/TUG-2 within an + STS-1_SPE/TUG-3 or VC-3. L must be 0 and ignored in all other + cases. + + 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 VT3 + SPE inside the corresponding VT Group; these values MUST 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 + corresponding VT_Group/TUG-2. M=6->9 indicates a specific + VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2. + + + +Mannie & Papadimitriou Standards Track [Page 13] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + Note that a label always has to be interpreted according the + SONET/SDH traffic parameters; i.e., a label by itself does not allow + knowing which signal is being requested (a label is context + sensitive). + + The label format defined in this section, referred to as SUKLM, MUST + be used for any SONET/SDH signal requests that are not transparent; + i.e., when all Transparency (T) bits defined in 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 format as defined in [RFC3471]. + + 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 + + + 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 + + + + + + + + + +Mannie & Papadimitriou Standards Track [Page 14] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + 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: + + M SDH TUG-2 SONET VTG + ------------------------------------------------- + 0 other other + 1 - 1st VT3 SPE + 2 - 2nd VT3 SPE + 3 1st VC-12 1st VT2 SPE + 4 2nd VC-12 2nd VT2 SPE + 5 3rd VC-12 3rd VT2 SPE + 6 1st VC-11 1st VT1.5 SPE + 7 2nd VC-11 2nd VT1.5 SPE + 8 3rd VC-11 3rd VT1.5 SPE + 9 4th VC-11 4th VT1.5 SPE + + Examples of Labels + + Example 1: the label for the STS-3c_SPE/VC-4 in the Sth + STS-3/AUG-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 + 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 + 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 + in 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. + + 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 + Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8. + + + + +Mannie & Papadimitriou Standards Track [Page 15] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + 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, + K=0, L=0, M=0. + + In case of contiguous concatenation, the label that is used is the + lowest label (value) of the contiguously concatenated signal, as + explained before. The higher part of the label indicates where the + 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 + zero, according to the field coding rules. For instance, when a VC-3 + in an STM-0 is requested, the label is S=0, U=0, K=0, L=0, M=0. When + a VC-11 in a VC-3 in an STM-0 is requested, the label is 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-3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM + label format and encoding is not applicable, and the label encoding + MUST follow the rules defined in [RFC3471], Section 3.2. + +4. Acknowledgements + + Valuable comments and input were received from the CCAMP mailing + list, where outstanding discussions took place. + + The authors would like to thank Richard Rabbat for his valuable + input, which lead to this revision. + +5. Security Considerations + + This document introduces no new security considerations to either + [RFC3473] or [RFC3472]. GMPLS security is described in Section 11 of + [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] for + CR-LDP. + +6. IANA Considerations + + Three values defined by IANA for RFC 3946 now apply to this document. + + Two RSVP C-Types in registry: + http://www.iana.org/assignments/rsvp-parameters + + - A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see + Section 2.2). + + - A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see Section + 2.2). + + + +Mannie & Papadimitriou Standards Track [Page 16] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + One LDP TLV Type in registry: + http://www.iana.org/assignments/ldp-namespaces + + - A type field for the SONET/SDH Traffic Parameters TLV (see Section + 2.3). + +Contributors + + Contributors are listed in alphabetical order: + + Stefan Ansorge (Alcatel) + Lorenzstrasse 10 + 70435 Stuttgart, Germany + EMail: stefan.ansorge@alcatel.de + + Peter Ashwood-Smith (Nortel) + PO. Box 3511 Station C, + Ottawa, ON K1Y 4H7, Canada + EMail:petera@nortelnetworks.com + + Ayan Banerjee (Calient) + 5853 Rue Ferrari + San Jose, CA 95138, USA + EMail: abanerjee@calient.net + + Lou Berger (Movaz) + 7926 Jones Branch Drive + McLean, VA 22102, USA + EMail: lberger@movaz.com + + Greg Bernstein (Ciena) + 10480 Ridgeview Court + Cupertino, CA 94014, USA + EMail: greg@ciena.com + + Angela Chiu (Celion) + One Sheila Drive, Suite 2 + Tinton Falls, NJ 07724-2658 + EMail: angela.chiu@celion.com + + John Drake (Calient) + 5853 Rue Ferrari + San Jose, CA 95138, USA + EMail: jdrake@calient.net + + + + + + + +Mannie & Papadimitriou Standards Track [Page 17] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + Yanhe Fan (Axiowave) + 100 Nickerson Road + Marlborough, MA 01752, USA + EMail: yfan@axiowave.com + + Michele Fontana (Alcatel) + Via Trento 30, + I-20059 Vimercate, Italy + EMail: michele.fontana@alcatel.it + + Gert Grammel (Alcatel) + Lorenzstrasse, 10 + 70435 Stuttgart, Germany + EMail: gert.grammel@alcatel.de + + Juergen Heiles (Siemens) + Hofmannstr. 51 + D-81379 Munich, Germany + EMail: juergen.heiles@siemens.com + + Suresh Katukam (Cisco) + 1450 N. McDowell Blvd, + Petaluma, CA 94954-6515, USA + EMail: suresh.katukam@cisco.com + + Kireeti Kompella (Juniper) + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089, USA + EMail: kireeti@juniper.net + + Jonathan P. Lang (Calient) + 25 Castilian + Goleta, CA 93117, USA + EMail: jplang@calient.net + + Fong Liaw (Solas Research) + EMail: fongliaw@yahoo.com + + Zhi-Wei Lin (Lucent) + 101 Crawfords Corner Rd + Holmdel, NJ 07733-3030, USA + EMail: zwlin@lucent.com + + Ben Mack-Crane (Tellabs) + EMail: ben.mack-crane@tellabs.com + + + + + + +Mannie & Papadimitriou Standards Track [Page 18] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + Dimitrios Pendarakis (Tellium) + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + EMail: dpendarakis@tellium.com + + Mike Raftelis (White Rock) + 18111 Preston Road + Dallas, TX 75252, USA + + Bala Rajagopalan (Tellium) + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + EMail: braja@tellium.com + + Yakov Rekhter (Juniper) + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089, USA + EMail: yakov@juniper.net + + Debanjan Saha (Tellium) + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + EMail: dsaha@tellium.com + + Vishal Sharma (Metanoia) + 335 Elan Village Lane + San Jose, CA 95134, USA + EMail: vsharma87@yahoo.com + + George Swallow (Cisco) + 250 Apollo Drive + Chelmsford, MA 01824, USA + EMail: swallow@cisco.com + + Z. Bo Tang (Tellium) + 2 Crescent Place, P.O. Box 901 + Oceanport, NJ 07757-0901, USA + EMail: btang@tellium.com + + Eve Varma (Lucent) + 101 Crawfords Corner Rd + Holmdel, NJ 07733-3030, USA + EMail: evarma@lucent.com + + Yangguang Xu (Lucent) + 21-2A41, 1600 Osgood Street + North Andover, MA 01845, USA + EMail: xuyg@lucent.com + + + +Mannie & Papadimitriou Standards Track [Page 19] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +Appendix 1. Signal Type Values Extension for VC-3 + + This appendix defines the following optional additional Signal + Type value for the Signal Type field of Section 2.1: + + Value Type + ----- --------------------- + 20 "VC-3 via AU-3 at the end" + + According to the ITU-T [G.707] recommendation, a VC-3 in the TU- + 3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured in + TUG-2s; however, a VC-3 in the AU-3 branch can be. In addition, a + VC-3 could be switched between the two branches, if required. + + A VC-3 circuit could be terminated on an ingress interface of an LSR + (e.g., forming a VC-3 forwarding adjacency). This LSR could then + want to demultiplex this VC-3 and switch internal low-order LSPs. + For implementation reasons, this could be only possible if the LSR + receives the VC-3 in the AU-3 branch. For example, for an LSR not + able to switch internally from a TU-3 branch to an AU-3 branch on its + incoming interface before demultiplexing and then switching the + content with its switch fabric. + + 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 branch. + + 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 penultimate LSR to + switch an incoming VC-3 received in any branch to the AU-3 branch on + the outgoing interface to the destination LSR. + + 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 the + network. The VC-3 signal type just indicates that a VC-3 in any + branch is suitable. + +Annex 1. Examples + + This annex defines examples of SONET and SDH signal coding. The + objective is to help the reader to understand how the traffic + parameter coding works and not to give examples of typical SONET or + SDH signals. + + As stated above, signal types are Elementary Signals to which + successive concatenation, multiplication, and transparency transforms + can be applied to obtain Final Signals. + + + + + +Mannie & Papadimitriou Standards Track [Page 20] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + 1. A VC-4 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 with + value 0 to a VC-4 Elementary Signal. + + 2. A VC-4-7v signal is formed by the application of RCC with value + 0, NCC with value 0, NVC with value 7 (virtual concatenation of + 7 components), MT with value 1, and T with value 0 to a VC-4 + Elementary Signal. + + 3. A VC-4-16c signal is formed by the application of RCC with value + 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 Signal. + + 4. An STM-16 signal with Multiplex Section layer transparency is + 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 Elementary Signal. + + 5. An STM-4 signal with Multiplex Section layer transparency is + 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 applied to + an STM-4 Elementary Signal. + + 6. An STM-256 signal with Multiplex Section layer transparency is + 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 applied to + an STM-256 Elementary Signal. + + 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 with value 0 to an STS-1 SPE Elementary Signal. + + 8. An STS-3c SPE signal is formed by the application of RCC with + 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-3c SPE Elementary Signal. + + 9. An STS-48c SPE signal is formed by the application of RCC with + 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-3c SPE Elementary Signal. + + 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 + components), MT with value 1, and T with value 0 to an STS-1 SPE + Elementary Signal. + + + + +Mannie & Papadimitriou Standards Track [Page 21] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + + 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 + concatenation of 9 STS-3c), MT with value 1, and T with value 0 + to an STS-3c SPE Elementary Signal. + + 12. An STS-12 signal with Section layer (full) transparency is + 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 1 to an + STS-12 Elementary Signal. + + 13. A 3 x STS-768c SPE signal is formed by the application of RCC + with value 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. + + 14. A 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 + value 0 to a VC-4 Elementary Signal. + + 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 1 1 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 1 1 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 + + + + + + + + + + + + + + + +Mannie & Papadimitriou Standards Track [Page 22] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +Normative References + + [G.707] ITU-T Recommendation G.707, "Network Node Interface for + the Synchronous Digital Hierarchy", October 2000. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 1997. + + [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services", RFC 2210, September 1997. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, + L., Doolan, P., Worster, T., Feldman, N., Fredette, A., + Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. + Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, + January 2002. + + [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching + (GMPLS) Signaling Functional Description", RFC 3471, + January 2003. + + [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- + Protocol Label Switching (GMPLS) Signaling Constraint- + based Routed Label Distribution Protocol (CR-LDP) + Extensions", RFC 3472, January 2003. + + [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching + (GMPLS) Signaling Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE) Extensions", RFC 3473, January + 2003. + + [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching + (GMPLS) Architecture", RFC 3945, October 2004. + + [T1.105] "Synchronous Optical Network (SONET): Basic Description + Including Multiplex Structure, Rates, and Formats", ANSI + T1.105, October 2000. + + + + + + +Mannie & Papadimitriou Standards Track [Page 23] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +Authors' Addresses + + Eric Mannie + Perceval + Rue Tenbosch, 9 + 1000 Brussels + Belgium + + Phone: +32-2-6409194 + EMail: eric.mannie@perceval.net + + + Dimitri Papadimitriou + Alcatel + Copernicuslaan 50 + B-2018 Antwerpen, Belgium + + Phone: +32 3 240-8491 + EMail: dimitri.papadimitriou@alcatel.be + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mannie & Papadimitriou Standards Track [Page 24] + +RFC 4606 GMPLS Extensions for SONET & SDH Control August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Mannie & Papadimitriou Standards Track [Page 25] + |