--- 1/draft-ietf-mpls-generalized-cr-ldp-06.txt 2006-02-05 00:39:00.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-cr-ldp-07.txt 2006-02-05 00:39:00.000000000 +0100 @@ -1,110 +1,82 @@ Network Working Group Internet Draft Peter Ashwood-Smith - Editor (Nortel Networks) -Expiration Date: October 2002 Lou Berger - Editor (Movaz Networks) - Ayan Banerjee (Calient Networks) - Greg Bernstein (Ciena Corporation) - John Drake (Calient Networks) - Yanhe Fan (Axiowave Networks) - Don Fedyk (Nortel Networks) - Kireeti Kompella (Juniper Networks) - Eric Mannie (KPNQwest) - Jonathan P. Lang (Calient Networks) - Bala Rajagopalan (Tellium) - Yakov Rekhter (Juniper Networks) - Debanjan Saha (Tellium) - Vishal Sharma (Metanoia) - George Swallow (Cisco Systems) - Z. Bo Tang (Tellium) +Expiration Date: February 2003 Lou Berger - Editor (Movaz Networks) - April 2002 + August 2002 Generalized MPLS Signaling - CR-LDP Extensions - draft-ietf-mpls-generalized-cr-ldp-06.txt + draft-ietf-mpls-generalized-cr-ldp-07.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract - This document describes extensions to CR-LDP signaling required to - support Generalized MPLS. Generalized MPLS extends MPLS to encompass - time-division (e.g. SONET/SDH ADMs), wavelength (optical lambdas) and - spatial switching (e.g. incoming port or fiber to outgoing port or - fiber). This document presents a CR-LDP specific description of the - extensions. A generic functional description and an RSVP-TE specific - description can be found in separate documents. + This document describes extensions to MPLS (Multi-Protocol Label + Switching) CR-LDP (Constraint-based Routed Label Distribution + Protocol) signaling required to support Generalized MPLS. Generalized + MPLS extends the MPLS control plane to encompass time-division (e.g., + Synchronous Optical Network and Synchronous Digital Hierarchy, + SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g. + incoming port or fiber to outgoing port or fiber). This document + presents a CR-LDP specific description of the extensions. A generic + functional description can be found in separate documents. Contents - 1 Introduction .............................................. 3 - 2 Label Related Formats .................................... 3 - 2.1 Generalized Label Request ................................. 4 - 2.1.1 Procedures ................................................ 4 - 2.1.2 Bandwidth Encoding ........................................ 5 - 2.2 Generalized Label ......................................... 5 - 2.2.1 Procedures ................................................ 6 - 2.3 Waveband Switching ........................................ 6 - 2.3.1 Procedures ................................................ 6 - 2.4 Suggested Label ........................................... 7 - 2.5 Label Set ................................................. 8 - 2.5.1 Procedures ................................................ 8 - 3 Bidirectional LSPs ........................................ 9 - 3.1 Procedures ................................................ 9 - 4 Notification on Label Error ............................... 10 - 5 Explicit Label Control .................................... 11 - 5.1 Procedures ................................................ 11 - 6 Protection TLV ............................................ 12 - 6.1 Procedures ................................................ 12 - 7 Administrative Status Information ......................... 13 - 7.1 Admin Status TLV .......................................... 13 - 7.2 REQUEST and MAPPING Message Procedures .................... 13 - 7.2.1 Deletion procedure ........................................ 14 - 7.3 Notification Message Procedures ........................... 15 - 7.3.1 Compatibility and Error Procedures ........................ 15 - 8 Control Channel Separation ................................ 15 - 8.1 Interface Identification .................................. 16 - 8.2 Procedures ................................................ 17 - 8.3 Errored Interface Identification .......................... 17 - 8.3.1 IF_ID Status TLVs ......................................... 17 - 8.3.2 Procedures ................................................ 18 - 9 Fault Handling ......................................... 19 -10 Acknowledgments ........................................... 19 -11 Security Considerations ................................... 19 -12 IANA Considerations ....................................... 19 -13 References ................................................ 20 -13.1 Normative References ...................................... 20 -13.2 Informative References .................................... 20 -14 Authors' Addresses ........................................ 21 - -[Editor's note: changes to be removed prior to publication as an RFC.] -Changes from previous version: - -o Reorder author's list to indicate primary contact -o Split references section -o Fixed formatting of section 7.2.1 -o Minor editorial changes and clarifications + 1 Introduction ................................................ 3 + 2 Label Related Formats ...................................... 3 + 2.1 Generalized Label Request ................................... 3 + 2.2 Generalized Label ........................................... 5 + 2.3 Waveband Switching .......................................... 6 + 2.4 Suggested Label ............................................. 7 + 2.5 Label Set ................................................... 7 + 3 Bidirectional LSPs .......................................... 9 + 3.1 Procedures .................................................. 9 + 4 Notification on Label Error ................................. 9 + 5 Explicit Label Control ...................................... 10 + 5.1 Procedures .................................................. 10 + 6 Protection TLV .............................................. 11 + 6.1 Procedures .................................................. 12 + 7 Administrative Status Information ........................... 12 + 7.1 Admin Status TLV ............................................ 12 + 7.2 REQUEST and MAPPING Message Procedures ...................... 13 + 7.3 Notification Message Procedures ............................. 14 + 8 Control Channel Separation .................................. 15 + 8.1 Interface Identification .................................... 15 + 8.2 Errored Interface Identification ............................ 17 + 9 Fault Handling ........................................... 18 +10 Acknowledgments ............................................. 19 +11 Security Considerations ..................................... 19 +12 IANA Considerations ......................................... 19 +13 Intellectual Property Considerations ........................ 20 +14 References .................................................. 20 +14.1 Normative References ........................................ 20 +14.2 Informative References ...................................... 21 +15 Contributors ................................................ 21 +16 Contact Addresses ........................................... 24 1. Introduction Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [GMPLS-SIG]. This document presents CR-LDP specific formats and mechanisms needed to support all four classes of @@ -126,25 +98,26 @@ document are to be interpreted as described in [RFC2119]. 2. Label Related Formats This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets. 2.1. Generalized Label Request - A REQUEST message SHOULD contain as specific an LSP Encoding Type as - possible to allow the maximum flexibility in switching by transit - LSRs. A Generalized Label Request TLV is set by the ingress node, - transparently passed by transit nodes, and used by the egress node. - The Switching Type field may also be updated hop-by-hop. + A REQUEST message SHOULD contain as specific an LSP (Label Switched + Path) Encoding Type as possible to allow the maximum flexibility in + switching by transit LSRs. A Generalized Label Request TLV is set by + the ingress node, transparently passed by transit nodes, and used by + the egress node. The Switching Type field may also be updated hop- + by-hop. The format of a Generalized Label Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -172,21 +145,21 @@ node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Encoding" indication. Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a NOTIFICATION message with a "Routing problem/Switching Type" indication. The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a - NOTIFICATION message, with a "Routing problem/Unsupported GPID" + NOTIFICATION message, with a "Routing problem/Unsupported G-PID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G- PID during the processing of the MAPPING message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. The generated NOTIFICATION message MAY include an Acceptable Label Set, see Section 4. When an error message is not generated, normal processing occurs. In the transit case this will typically result in a REQUEST message @@ -647,20 +620,22 @@ The choice of the data interface to use is always made by the sender of the REQUEST message. The choice of the data interface is indicated by the sender of the REQUEST message by including the data channel's interface identifier in the message using a new Interface TLV. type. For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the REQUEST sender explicitly identifies the component interface used in each direction. +8.1.1. Interface ID TLV + The format of IPV4 Interface ID in REQUEST, MAPPING Messages 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Next/Previous Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Logical Interface ID | @@ -679,54 +654,56 @@ | Logical Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID TLVS see [GMPLS-SIG] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. See [RFC3212] for a description of signaling address. See [GMPLS- SIG] for a description of parameters and encoding of TLVs. -8.2. Procedures +8.1.2. Procedures An IF_ID TLV is used on links where there is not a one-to- one association of a control channel to a data channel, see [GMPLS- SIG]. The LDP session uses the IF_ID TLV to identify the data channel(s) associated with the LSP. For a unidirectional LSP, a downstream data channel MUST be indicated. For bidirectional LSPs, a common downstream and upstream data channel is normally indicated. In the special case where a bidirectional LSP that traverses a bundled link, it is possible to specify a downstream data channel that differs from - the upstream data channel. Data channels are specified from the view - point of the sender of the Path message. The IF_ID TLV SHOULD NOT be - used when no TLVs are needed. + the upstream data channel. Data channels are specified from the + viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD + NOT be used when no TLVs are needed. A node receiving one or more IF_ID TLVs in a REQUEST message saves their values and returns them in the subsequent MAPPING message sent to the node that originated the TLVs. - As with [MPLS-TE], the node originating an IF_ID TLV must ensure that - the selected outgoing interface is consistent with the outgoing ER - TLV. A node that receives an IF_ID TLV SHOULD check whether the + Note, the node originating an IF_ID TLV MUST ensure that the selected + outgoing interface, as specified in the IF_ID TLV, is consistent with + an ERO. A node that receives an IF_ID TLV SHOULD check whether the information carried in this TLV is consistent with the information - carried in a received ER TLV, and if not it MUST send a LABEL ABORT - Message with the status code of "Bad Explicit Routing TLV Error" - toward the sender. + carried in a received ERO, and if not it MUST send a LABEL ABORT + Message with the error code "Routing Error" and error value of "Bad + Explicit Routing TLV Error" toward the sender. This check CANNOT be + performed when the initial ERO subobject is not the incoming + interface. -8.3. Errored Interface Identification +8.2. Errored Interface Identification There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID Status TLV are defined. -8.3.1. IF_ID Status TLVs +8.2.1. IF_ID Status TLVs The format of the IPv4 IF_ID Status TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Next/Previous Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -753,21 +729,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [RFC3036] for a description of status code value fields. See [GMPLS-SIG] for a description of parameters and encoding of TLVs. -8.3.2. Procedures +8.2.2. Procedures Nodes wishing to indicate that an error is related to a specific interface SHOULD use the appropriate IF_ID Status TLV in the corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status TLV SHOULD be generated and processed as any other Status TLV, see [RFC3036]. 9. Fault Handling In optical transport networks, failures in the out-of-fiber signaling @@ -796,134 +772,149 @@ Valuable comments and input were received from a number of people, notably Adrian Farrel. 11. Security Considerations This draft introduce no new security considerations to [RFC3212]. 12. IANA Considerations - This draft uses the LDP [RFC 3031] name spaces, which require - assignment for the following TLVs. + This draft uses the LDP [RFC3036] name spaces, see + http://www.iana.org/assignments/ldp-namespaces, which require + assignment for the following TLVs: o Generalized Label Request (TLV TBA) o Generalized Label (TLV TBA) o Upstream Label (TLV TBA) o Label Set (TLV TBA) o Waveband Label (TLV TBA) o ER-Hop (TLV TBA) o Acceptable Label Set (TLV TBA) o Admin Status (TLV TBA) o Interface ID (TLV TBA) o IPV4 Interface ID (TLV TBA) o IPV6 Interface ID (TLV TBA) o IPv4 IF_ID Status (TLV TBA) o IPv6 IF_ID Status (TLV TBA) -13. References +13. Intellectual Property Considerations -13.1. Normative References + This section is taken from Section 10.4 of [RFC2026]. + + 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 BCP-11. 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. + +14. References + +14.1. Normative References [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, - draft-ietf-mpls-generalized-signaling-08.txt, - April 2002. + draft-ietf-mpls-generalized-signaling-09.txt, + August 2002. [RFC3036] Andersson et al., "LDP Specification", RFC 3036. [RFC3212] Jamoussi et al., "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. -13.2. Informative References +14.2. Informative References [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, - draft-ietf-mpls-generalized-rsvp-te-07.txt, - April 2002. + draft-ietf-mpls-generalized-rsvp-te-08.txt, + August 2002. [LDP-FT] Farrel, A. et al, "Fault Tolerance for LDP and CR-LDP", Internet Draft, draft-ietf-mpls-ldp-ft-02.txt, May 2001. [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, Sep., 2001. [MPLS-UNNUM] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling Unnumbered Links in CR-LDP", Internet Draft, - draft-ietf-mpls-crldp-unnum-02.txt, Sep. 2001 + draft-ietf-mpls-crldp-unnum-07.txt, July 2002. + +[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," + RFC 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. -14. Authors' Addresses +15. Contributors Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada Phone: +1 613 763 4534 Email: petera@nortelnetworks.com Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138 Phone: +1 408 972-3645 Email: abanerjee@calient.net - - Lou Berger Editor & Primary Point of Contact + Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102 Phone: +1 703 847-1801 Email: lberger@movaz.com Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014 Phone: +1 408 366 4713 Email: greg@ciena.com - John Drake - Calient Networks - 5853 Rue Ferrari - San Jose, CA 95138 - Phone: +1 408 972 3720 - Email: jdrake@calient.net Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752 Phone: + 1 774 348 4627 Email: yfan@axiowave.com Don Fedyk Nortel Networks Corp. 600 Technology Park Billerica MA 01821 Phone: +1 978 288 3041 Fax: +1 978 288 0620 Email: dwfedyk@nortelnetworks.com - Kireeti Kompella - Juniper Networks, Inc. - 1194 N. Mathilda Ave. - Sunnyvale, CA 94089 - Email: kireeti@juniper.net - Jonathan P. Lang Calient Networks 25 Castilian Goleta, CA 93117 Email: jplang@calient.net Eric Mannie KPNQwest Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium @@ -924,32 +915,28 @@ Email: jplang@calient.net Eric Mannie KPNQwest Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658 56 52 Mobile: +32 496 58 56 52 Fax: +32 2 658 51 18 Email: eric.mannie@kpnqwest.com - Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Phone: +1 732 923 4237 Fax: +1 732 923 9804 Email: braja@tellium.com - Yakov Rekhter - Juniper Networks, Inc. - Email: yakov@juniper.net Debanjan Saha Tellium Optical Systems 2 Crescent Place Oceanport, NJ 07757-0901 Phone: +1 732 923 4264 Fax: +1 732 923 9804 Email: dsaha@tellium.com Vishal Sharma @@ -968,11 +955,29 @@ Z. Bo Tang Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Phone: +1 732 923 4231 Fax: +1 732 923 9804 Email: btang@tellium.com -Generated on: Thu Apr 25 12:58:02 2002 +16. Contact Addresses + + Peter Ashwood-Smith + Nortel Networks Corp. + P.O. Box 3511 Station C, + Ottawa, ON K1Y 4H7 + Canada + Phone: +1 613 763 4534 + Email: petera@nortelnetworks.com + + Lou Berger + Movaz Networks, Inc. + 7926 Jones Branch Drive + Suite 615 + McLean VA, 22102 + Phone: +1 703 847-1801 + Email: lberger@movaz.com + +Generated on: Wed Aug 28 10:40:59 2002