diff options
Diffstat (limited to 'doc/rfc/rfc3476.txt')
| -rw-r--r-- | doc/rfc/rfc3476.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3476.txt b/doc/rfc/rfc3476.txt new file mode 100644 index 0000000..d9dd0a6 --- /dev/null +++ b/doc/rfc/rfc3476.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group B. Rajagopalan +Request for Comments: 3476 Tellium, Inc. +Category: Informational March 2003 + + + Documentation of IANA Assignments for Label Distribution Protocol + (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation + Protocol-Traffic Engineering (RSVP-TE) Extensions + for Optical UNI Signaling + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Optical Interworking Forum (OIF) has defined extensions to the + Label Distribution Protocol (LDP) and the Resource ReSerVation + Protocol (RSVP) for optical User Network Interface (UNI) signaling. + These extensions consist of a set of new data objects and error + codes. This document describes these extensions. + +1. Introduction + + The OIF UNI signaling specification is described in [8]. This + specification utilizes IETF protocol standards as well as IETF work + in progress. Specifically, the following IETF specifications are + used: + + o Label distribution protocol (LDP) [6] + o Resource reservation protocol (RSVP) [5] + o GMPLS signaling and GMPLS extensions for SONET/SDH [4] + o GMPLS RSVP-TE and CR-LDP extensions [2, 3] + + The aim of the OIF UNI specification is the maximal re-use of IETF + protocol definitions. A few extensions to IETF protocols, however, + have been defined to serve UNI-specific needs. These extensions are + described in this document. + + + + + + + +Rajagopalan Informational [Page 1] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +2. LDP Extensions for UNI Signaling + + The LDP extensions for UNI signaling consist of new TLVs that capture + UNI-specific parameters and new UNI-specific status codes. The new + TLVs are Source ID (3 TLVs), Destination ID (3 TLVs), Egress Label, + Local Connection ID, Diversity, Contract ID, and UNI Service Level + [8]. These are described below. The new status codes are assigned + from the private use space of LDP codes, as described in [8]. The + UNI specification [8] also defines two new LDP messages, Status + Enquiry and Status Response. These messages have been obsoleted and + hence no code points are requested in this document for them. + +2.1 Source ID TLVs + + Three TLVs have been defined to encode the Source ID. The content and + usage of these TLVs are described in [8]. + +2.1.1 IPv4 Source ID + + 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|Source ID Type (0x0960) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.2 IPv6 Source ID + + 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|Source ID Type (0x0961) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + +Rajagopalan Informational [Page 2] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +2.1.3 NSAP Source ID + + 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|Source ID Type (0x0962) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.2 Destination ID TLVs + + Three TLVs have been defined to encode the Destination ID. The + content and usage of these TLVs are described in [8]. + +2.2.1 IPv4 Destination ID + + 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|Dest ID Type (0x0963) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.2.2 IPv6 Destination ID + + 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|Dest ID Type (0x0964) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + +Rajagopalan Informational [Page 3] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +2.2.3 NSAP Destination ID + + 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|Dest ID Type (0x0965) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.3 Egress Label TLV + + The Egress Label TLV is encoded as: + + 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|Egress Label (0x966) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The content and usage of this TLV are described in [8]. + +2.4 Local Connection ID TLV + + The Local Connection ID TLV is encoded as: + + 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|Local Conn. ID (0x967) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The content and usage of this TLV are described in [8]. + + + + + + + + +Rajagopalan Informational [Page 4] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +2.5 Diversity TLV + + The Diversity TLV is encoded as: + + 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|Diversity (0x968) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The content and usage of this TLV are described in [8]. + +2.6 Contract ID TLV + + The Contract ID TLV is encoded as: + + 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|Contract ID (0x969) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The content and usage of this TLV are described in [8]. + +2.7 UNI Service Level TLV + + The UNI Service Level TLV is encoded as: + + 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|Service Level (0x970) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Contents ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The content and usage of this TLV are described in [8]. + + + + +Rajagopalan Informational [Page 5] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +3. RSVP Extensions for UNI Signaling + + A single new object class, called "Generalized_UNI" is defined. In + addition, extension to the RSVP session object and new UNI-specific + error codes are defined. These are described below. + +3.1 Generalized_UNI Object + + The GENERALIZED_UNI object 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length (>8) | CNum(229) | C-Type (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // (Subobjects) // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Subobjects: + + The contents of a GENERALIZED_UNI object are a series of variable- + length data items. The common format of the sub-objects is shown + below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Type | Sub-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // Value // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following sub-objects are defined. The contents of these sub- + objects are described in [8]: + + - Source Transport Network Assigned (TNA) Address sub-object: + Type = 1. The following sub-types are defined: + + Ipv4 (Sub-type = 1); + Ipv6 (Sub-type = 2); + NSAP (Sub-type = 3). + + - Destination TNA Address sub-object: Type = 2; + The following sub-types are defined: + + Ipv4 (Sub-type = 1); + Ipv6 (Sub-type = 2); + NSAP (Sub-type = 3). + + + +Rajagopalan Informational [Page 6] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + + - Diversity sub-object: Type = 3, Sub-type = 1. + - Egress label sub-object: Type = 4, Sub-type = 1. + - Service level sub-object: Type = 5, Sub-type = 1. + +3.2 UNI_Ipv4_Session Object + + This object [7] has the following format: + + UNI_IPv4_SESSION object: Class = 1, C-Type = 11 + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length (16) | Class-Num(1) |C-Type (11) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MUST be zero | Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extended IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The C-Type value (11) will distinguish UNI-related RSVP Sessions + from other RSVP sessions. The usage of this object is described in + [8]. + +3.3 Error Codes + + UNI-specific errors fall under the "Routing Problem" (error code = + 24) [7] and "Policy Control Failure" (error code = 2) [5] errors, and + they require the assignment of sub-codes. The following is the list + of errors and proposed assignments of sub-codes: + + - Routing Problem: Diversity not available (Error code = 24, sub- + code = 100) + - Routing Problem: Service level not available (Error code = 24, + sub-code = 101) + - Routing problem: Invalid/Unknown connection ID (Error code = 24, + sub-code = 102) + - Policy control failure: Unauthorized sender (Error code = 2, sub- + code = 100) + - Policy control failure: Unauthorized receiver (Error code = 2, + sub-code = 101) + + + + + + + + +Rajagopalan Informational [Page 7] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +4. IANA Considerations + + The OIF UNI 1.0 specification defines new objects and error codes + under LDP and RSVP. The majority of these extensions require code + point assignments via IETF consensus action. These are summarized + below. + +4.1 LDP Messages, TLVs and Status Codes + + TLV types 0x0960 - 0x0970 as described in Sections 2.1 - 2.7 above. + + UNI-specific status codes have been allocated out of the Private Use + space, i.e., 0x3Fxxxxxx. These do not require IANA administration. + +4.2 RSVP Object Class and Error Codes + + Generalized_UNI object class (Section 3.1), Class Number 229, C-Type + 1. Further sub-objects are defined, with Type numbers 1-5 and + various Sub-Type numbers, as described in Section 3.1. The code + points for the Generalized_UNI object and the associated sub-objects + require IANA administration. + + UNI_Ipv4_Session Object (Class-Num = 1, C-Type = 11), as described in + Section 3.2. + + UNI-specific errors fall under the Routing Problem and Policy Control + Failure errors (error codes 24 and 2). Sub-codes under error code 24 + are 100, 101 and 102, as described in Section 3.3. Sub-codes under + error code 2 are 100 and 101, as described in Section 3.3. + +5. Security Considerations + + Security considerations related to RSVP, RSVP-TE and LDP are + described in Section 2.8, Section 6 and Section 5 of RFCs 2205 [5], + 3209 [9] and 3036 [6], respectively. Security considerations + pertaining to UNI signaling using the extensions described in this + document and how these relate to the security aspects of RSVP, RSVP- + TE and LDP are described in Section 13.4 of the UNI specification + [8]. + +6. References + + [1] Berger, L., Editor, "Generalized Multi-Protocol Label Switching + (MPLS) Signaling Functional Description", RFC 3471, January 2003. + + [2] Berger, L., Editor, "Generalized Multi-Protocol Label Switching + (MPLS) Signaling Resource ReserVation Protocol-Traffic + Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. + + + +Rajagopalan Informational [Page 8] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + + [3] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi- + Protocol Label Switching (MPLS) Signaling Constraint-based Routed + Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, + January 2003. + + [4] E. Mannie, et al., "GMPLS Extensions for SONET and SDH Control", + Work in Progress. + + [5] Braden, R., Editor, Zhang, L., Berson, S., Herzog, S. and S. + Jamin, "RSVP Functional Specification", RFC 2205, September 1997. + + [6] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. + Thomas, "LDP Specification", RFC 3036, January 2001. + + [7] 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. + + [8] UNI 1.0 Signaling Specification, The Optical Internetworking + Forum, http://www.oiforum.com/public/UNI_1.0_ia.html + +7. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in RFC 2028. + + Copies of claims of rights made available for publication 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 implementors or users of this + specification can be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + +Rajagopalan Informational [Page 9] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +8. Author's Address + + Bala Rajagopalan + Tellium, Inc. + 2 Crescent Place + Ocean Port, NJ 07757 + + Phone: +1-732-923-4237 + EMail: braja@tellium.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rajagopalan Informational [Page 10] + +RFC 3476 LDP & RSVP Extensions for Optical UNI Signaling March 2003 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rajagopalan Informational [Page 11] + |