--- 1/draft-ietf-mpls-generalized-rsvp-te-05.txt 2006-02-05 00:39:06.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-rsvp-te-06.txt 2006-02-05 00:39:06.000000000 +0100 @@ -1,33 +1,33 @@ Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Internet Draft Ayan Banerjee (Calient Networks) -Expiration Date: April 2002 Lou Berger (Movaz Networks) +Expiration Date: May 2002 Lou Berger (Movaz Networks) Greg Bernstein (Ciena Corporation) John Drake (Calient Networks) Yanhe Fan (Axiowave Networks) Kireeti Kompella (Juniper Networks, Inc.) Jonathan P. Lang (Calient Networks) Fong Liaw (Zaffire Inc.) Eric Mannie (EBONE) Ping Pan (Juniper Networks, Inc.) Bala Rajagopalan (Tellium, Inc.) Yakov Rekhter (Juniper Networks, Inc.) Debanjan Saha (Tellium, Inc.) Vishal Sharma (Metanoia, Inc.) George Swallow (Cisco Systems) Z. Bo Tang (Tellium, Inc.) - October 2001 + November 2001 Generalized MPLS Signaling - RSVP-TE Extensions - draft-ietf-mpls-generalized-rsvp-te-05.txt + draft-ietf-mpls-generalized-rsvp-te-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 @@ -46,78 +46,65 @@ time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents an RSVP-TE specific description of the extensions. A CR-LDP specific description can be found in [GMPLS-LDP]. A generic functional description is presented in [GMPLS-SIG]. Contents 1 Introduction ................................................ 4 - 2 Label Related Formats ...................................... 5 - 2.1 Generalized Label Request Object ............................ 5 + 2 Label Related Formats ...................................... 4 + 2.1 Generalized Label Request Object ............................ 4 2.2 Generalized Label Object .................................... 6 2.3 Waveband Switching .......................................... 7 2.4 Suggested Label ............................................. 8 2.5 Label Set ................................................... 8 3 Bidirectional LSPs .......................................... 10 3.1 Procedures .................................................. 10 3.2 Contention Resolution ....................................... 11 4 Notification ................................................ 11 - 4.1 Acceptable Label Set Object ................................. 12 + 4.1 Acceptable Label Set Object ................................. 11 4.2 Notify Request Objects ...................................... 12 - 4.3 Notify Message .............................................. 14 + 4.3 Notify Message .............................................. 13 4.4 Removing State with a PathErr message ....................... 15 5 Explicit Label Control ...................................... 16 - 5.1 Label ERO subobject ......................................... 17 + 5.1 Label ERO subobject ......................................... 16 5.2 Label RRO subobject ......................................... 18 6 Protection Object ........................................... 19 - 6.1 Procedures .................................................. 20 - 7 Administrative Status Information ........................... 20 - 7.1 Admin Status Object ......................................... 20 + 6.1 Procedures .................................................. 19 + 7 Administrative Status Information ........................... 19 + 7.1 Admin Status Object ......................................... 19 7.2 Path and Resv Message Procedures ............................ 20 7.3 Notify Message Procedures ................................... 22 8 Control Channel Separation .................................. 23 8.1 Interface Identification .................................... 23 8.2 Errored Interface Identification ............................ 25 - 9 Fault Handling .............................................. 27 + 9 Fault Handling .............................................. 26 9.1 Restart_Cap Object .......................................... 27 - 9.2 Processing of Restart_Cap Object ............................ 28 + 9.2 Processing of Restart_Cap Object ............................ 27 9.3 Modification to Hello Processing to Support State Recovery .. 28 9.4 Control Channel Faults ...................................... 29 9.5 Nodal Faults ................................................ 29 10 RSVP Message Formats and Handling ........................... 32 10.1 RSVP Message Formats ........................................ 32 10.2 Addressing Path and PathTear Messages ...................... 34 -11 Acknowledgments ............................................. 35 -12 Security Considerations ..................................... 35 +11 Acknowledgments ............................................. 34 +12 Security Considerations ..................................... 34 13 IANA Considerations ......................................... 35 14 References .................................................. 36 15 Authors' Addresses .......................................... 37 [Editor's note: changes to be removed prior to publication as an RFC.] Changes from previous version: -o Revised Admin Status Usage - (per comments and also removed potential race condition) -o Clarified text related to interface bundling - (To be consistent with updated bundling draft.) -o Added IF_ID ERROR_SPEC Object - (Per comments, supports Control Channel Separation by allowing - identification of errored interface.) -o Added U bit to Label RRO subobject - (Per comment, to match defined ERO.) -o Clarified usage of Restart_Cap -o Replaced use of Suggested_Label during recovery with new Recovery_Label - (Per last WG session) -o Added IANA Considerations 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 RSVP-TE @@ -174,20 +161,25 @@ dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER hops when using tunnels see [MPLS-HIERARCHY]. Transit and egress nodes MUST verify that the node itself and, where appropriate, that the interface or tunnel on which the traffic will be transmitted can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a PathErr 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 PathErr + 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 PathErr message, with a "Routing problem/Unsupported L3PID" 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 Resv message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. The generated ResvErr message MAY include an Acceptable Label Set, see Section 4.1. @@ -688,32 +679,32 @@ C-Type The C-Type of the included Label Object. Copied from the Label Object. 5.1.1. Procedures The Label subobject follows a subobject containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on - which it is to be used. The preceding subobject must be a strict - object. Up to two label subobjects may be present, one for the - downstream label and one for the upstream label. The following - SHOULD result in "Bad EXPLICIT_ROUTE object" errors: + which it is to be used. Up to two label subobjects may be present, + one for the downstream label and one for the upstream label. The + following SHOULD result in "Bad EXPLICIT_ROUTE object" errors: - If the first label subobject is not preceded by a subobject containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link. - For a label subobject to follow a subobject that has the L-bit set - On unidirectional LSP setup, for there to be a label subobject with the U-bit set - For there to be two label subobjects with the same U-bit values + To support the label subobject, a node must check to see if the subobject following its associate address/interface is a label subobject. If it is, one subobject is examined for unidirectional LSPs and two subobjects for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message. If the U-bit of the subobject being examined is set (1), then value of the label is label to be used for upstream traffic associated with @@ -1004,26 +997,29 @@ TLVs. 8.1.2. Procedures An IF_ID RSVP_HOP object is used in place of previously defined RSVP_HOP objects. It 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 Hop Address and Logical Interface Handle fields are used per standard RSVP [RFC2205]. - TLVs are used to identify the data channel(s) associated with the - LSP. For a unidirectional LSP, a forward channel MUST be indicated. - For a bidirectional LSP that uses bundled links, a reverse channel - MUST be indicated. Data channels are specified from the view point - of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD - NOT be used when no TLVs are needed. + TLVs are used to identify the data channel(s) associated with an 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 RSVP_HOP object SHOULD NOT be + used when no TLVs are needed. A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs. As with [MPLS-TE], the node originating an IF_ID object must ensure that the selected outgoing interface is consistent with the outgoing ERO. A node that receives an IF_ID object SHOULD check whether the information carried in this object is consistent with the information carried in a received ERO, and if not it MUST send a PathErr with the @@ -1254,21 +1250,23 @@ defined procedures. If the MPLS forwarding table entry is found, the appropriate RSVP state is created, the entry is bound to the LSP associated with the message, and related forwarding state should be considered as valid and refreshed. Normal Path message processing should also be conducted. When sending the corresponding outgoing Path message the node SHOULD include a Suggested_Label object with a label value matching the outgoing label from the now restored forwarding entry. The outgoing interface SHOULD also be selected based on the - forwarding entry. + forwarding entry. In the special case where a restarting node also + has a restating downstream neighbor, a Recovery_Label object should + be used instead of a Suggested_Label object. Additionally, for bidirectional LSPs, the node extracts the label from the UPSTREAM_LABEL object carried in the received Path message, and searches its MPLS forwarding table for an entry whose outgoing label is equal to the label carried in the object (in the case of link bundling, this may also involved first identifying the appropriate incoming component link). If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously @@ -1509,27 +1507,27 @@ [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in RSVP-TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-02.txt, August 2001 [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, - draft-ietf-mpls-generalized-cr-ldp-01.txt, - February 2001. + draft-ietf-mpls-generalized-cr-ldp-05.txt, + November 2001. [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, - draft-ietf-mpls-generalized-signaling-02.txt, - February 2001. + draft-ietf-mpls-generalized-signaling-07.txt, + November 2001. [PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE", Internet Draft, draft-pan-rsvp-te-restart-01.txt, July 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, @@ -1655,11 +1654,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: Mon Oct 1 01:20:20 EDT 2001 +Generated on: Wed Nov 21 15:26:44 EST 2001