--- 1/draft-ietf-mpls-generalized-cr-ldp-05.txt 2006-02-05 00:39:00.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-cr-ldp-06.txt 2006-02-05 00:39:00.000000000 +0100 @@ -1,32 +1,33 @@ -Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) -Internet Draft Ayan Banerjee (Calient Networks) -Expiration Date: May 2002 Lou Berger (Movaz Networks) +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 Corp.) - Kireeti Kompella (Juniper Networks, Inc.) - Eric Mannie (EBONE) + Don Fedyk (Nortel Networks) + Kireeti Kompella (Juniper Networks) + Eric Mannie (KPNQwest) Jonathan P. Lang (Calient Networks) - Bala Rajagopalan (Tellium, Inc.) - Yakov Rekhter (Juniper Networks, Inc.) - Debanjan Saha (Tellium, Inc.) - Vishal Sharma (Metanoia, Inc.) + Bala Rajagopalan (Tellium) + Yakov Rekhter (Juniper Networks) + Debanjan Saha (Tellium) + Vishal Sharma (Metanoia) George Swallow (Cisco Systems) - Z. Bo Tang (Tellium, Inc.) + Z. Bo Tang (Tellium) - November 2001 + April 2002 Generalized MPLS Signaling - CR-LDP Extensions - draft-ietf-mpls-generalized-cr-ldp-05.txt + draft-ietf-mpls-generalized-cr-ldp-06.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 @@ -35,73 +36,74 @@ 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 ADMs), wavelength (optical lambdas) and + 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. An RSVP-TE specific description can be found in [GMPLS- - RSVP]. A generic functional description is presented in [GMPLS-SIG]. + extensions. A generic functional description and an RSVP-TE specific + 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 ................................................ 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 ........................... 14 + 7.3 Notification Message Procedures ........................... 15 7.3.1 Compatibility and Error Procedures ........................ 15 8 Control Channel Separation ................................ 15 - 8.1 Interface Identification .................................. 15 - 8.2 Procedures ................................................ 16 + 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 ......................................... 18 + 9 Fault Handling ......................................... 19 10 Acknowledgments ........................................... 19 11 Security Considerations ................................... 19 12 IANA Considerations ....................................... 19 13 References ................................................ 20 -14 Authors' Addresses ........................................ 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 Revised Admin Status Usage -o Clarified text related to interface bundling - (To be consistent with updated bundling draft.) -o Added IANA Considerations +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 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 @@ -128,20 +130,21 @@ 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -564,36 +567,47 @@ Mapping message containing an Admin_Status TLV with the same values set, with the exception of the R bit, as received in the corresponding Request message. 7.2.1. Deletion procedure In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP before tearing it down. In such circumstances the procedure SHOULD be followed when deleting - an LSP from the ingress: The ingress node precedes an LSP deletion by - inserting an Admin Status TLV in a Notification Message setting the - Reflect (R) and Delete (D) bits. Transit nodes process the Admin - Status TLV by passing the Notification message. The egress node May - respond with a Notification message with the Admin Status TLV. Upon - receiving the Admin Status TLV with the Delete (D) bit set in the - Notification message, the egress SHOULD respond with a LABEL WITHDRAW - message and normal CR-LDP processing takes place. + an LSP from the ingress: + + o The ingress node precedes an LSP deletion by inserting an + Admin Status TLV in a Notification Message setting the Reflect + (R) and Delete (D) bits. + + o Transit nodes process the Admin Status TLV by passing the + Notification message. The egress node May respond with a + Notification message with the Admin Status TLV. + + o Upon receiving the Admin Status TLV with the Delete (D) bit + set in the Notification message, the egress SHOULD respond + with a LABEL WITHDRAW message and normal CR-LDP processing + takes place. In such circumstances the procedure SHOULD be followed when deleting - an LSP from the egress: The egress node indicates its desire for - deletion by inserting an Admin Status TLV in a Notification message - and setting Delete (D) bit. Transit nodes process the Admin Status - TLV as described above. Upon receiving the Admin Status TLV with the - Delete (D) bit set in the Notification message, the ingress node - sends a LABEL RELEASE message downstream to remove the LSP and normal + an LSP from the egress: + + o The egress node indicates its desire for deletion by inserting + an Admin Status TLV in a Notification message and setting + Delete (D) bit. + + o Transit nodes process the Admin Status TLV as described above. + + o Upon receiving the Admin Status TLV with the Delete (D) bit + set in the Notification message, the ingress node sends a + LABEL RELEASE message downstream to remove the LSP and normal CR-LDP processing takes place. 7.3. Notification Message Procedures Subsequent messaging Admin Status messaging may be performed by Notification Messages. The ingress may begin the propagation of a Notification Message with an Admin Status TLV. Each subsequent node propagates the Notification with the Admin Status TLV from the ingress to the egress and then the egress node returns the Notification messages back Upstream carrying the Admin Status TLV. @@ -628,24 +642,24 @@ required support a control channel not being in-band with a data channel. 8.1. Interface Identification 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 [MPLS-BUNDLE] the upstream - interface is implied by the downstream interface. For bundling, the - REQUEST sender explicitly identifies the component interface used in - each direction. + 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -657,27 +671,27 @@ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Next/Previous Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Logical Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Interface ID TLVS see [GMLPS-SIG] | + | Interface ID TLVS see [GMPLS-SIG] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. - See [CR-LDP] for a description of signaling address. See [GMPLS-SIG] - for a description of parameters and encoding of TLVs. + See [RFC3212] for a description of signaling address. See [GMPLS- + SIG] for a description of parameters and encoding of TLVs. 8.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 @@ -777,21 +792,21 @@ draft-saha-rsvp-optical-signaling-00.txt draft-lang-mpls-rsvp-oxc-00.txt draft-kompella-mpls-optical-00.txt draft-fan-mpls-lambda-signaling-00.txt 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 [CR-LDP]. + 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. o Generalized Label Request (TLV TBA) o Generalized Label (TLV TBA) o Upstream Label (TLV TBA) o Label Set (TLV TBA) @@ -800,52 +815,52 @@ 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 -[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", - Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, Jul., 2001. +13.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. [RFC3036] Andersson et al., "LDP Specification", RFC 3036. -[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with - MPLS TE", Internet Draft, - draft-ietf-mpls-lsp-hierarchy-02.txt, Sep., 2001. +[RFC3212] Jamoussi et al., "Constraint-Based LSP Setup using LDP", + RFC 3212, January 2002. -[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 +13.2. Informative References [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, - draft-ietf-mpls-generalized-rsvp-te-06.txt, - November 2001. - -[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - - Signaling Functional Description", Internet Draft, - draft-ietf-mpls-generalized-signaling-07.txt, - November 2001. + draft-ietf-mpls-generalized-rsvp-te-07.txt, + April 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-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling - in MPLS Traffic Engineering", Internet Draft, - draft-kompella-mpls-bundle-05.txt, Sep., 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. 14. Authors' Addresses Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 @@ -845,28 +860,29 @@ 14. Authors' 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 + Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138 Phone: +1 408 972-3645 Email: abanerjee@calient.net - Lou Berger + Lou Berger Editor & Primary Point of Contact 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 @@ -901,37 +917,36 @@ Sunnyvale, CA 94089 Email: kireeti@juniper.net Jonathan P. Lang Calient Networks 25 Castilian Goleta, CA 93117 Email: jplang@calient.net Eric Mannie - EBONE + 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@ebone.com + 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 @@ -952,11 +968,11 @@ 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: Wed Nov 21 15:23:23 EST 2001 +Generated on: Thu Apr 25 12:58:02 2002