--- 1/draft-ietf-mpls-generalized-rsvp-te-07.txt 2006-02-05 00:39:08.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-rsvp-te-08.txt 2006-02-05 00:39:08.000000000 +0100 @@ -1,70 +1,60 @@ Network Working Group Lou Berger - Editor (Movaz Networks) -Internet Draft Peter Ashwood-Smith (Nortel Networks) -Expiration Date: October 2002 Ayan Banerjee (Calient Networks) - Greg Bernstein (Ciena Corporation) - John Drake (Calient Networks) - Yanhe Fan (Axiowave Networks) - Kireeti Kompella (Juniper Networks) - Jonathan P. Lang (Calient Networks) - Fong Liaw (Solas Research) - Eric Mannie (KPNQwest) - Ping Pan (Juniper Networks, Inc.) - Bala Rajagopalan (Tellium) - Yakov Rekhter (Juniper Networks) - Debanjan Saha (Tellium) - Vishal Sharma (Metanoia) - George Swallow (Cisco Systems) - Z. Bo Tang (Tellium) +Internet Draft +Expiration Date: February 2003 - April 2002 + August 2002 Generalized MPLS Signaling - RSVP-TE Extensions - draft-ietf-mpls-generalized-rsvp-te-07.txt + draft-ietf-mpls-generalized-rsvp-te-08.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 RSVP-TE 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 an RSVP-TE specific description of - the extensions. A generic functional description and a CR-LDP - specific description can be found in separate documents. + This document describes extensions to MPLS (Multi-Protocol Label + Switching) RSVP-TE (Resource ReserVation Protocol - Traffic + Engineering) 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 RSVP-TE 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 Object ............................ 3 - 2.2 Generalized Label Object .................................... 5 - 2.3 Waveband Switching .......................................... 6 - 2.4 Suggested Label ............................................. 7 - 2.5 Label Set ................................................... 7 + 2.2 Bandwidth Encoding .......................................... 5 + 2.3 Generalized Label Object .................................... 5 + 2.4 Waveband Switching .......................................... 6 + 2.5 Suggested Label ............................................. 7 + 2.6 Label Set ................................................... 7 3 Bidirectional LSPs .......................................... 9 3.1 Procedures .................................................. 9 3.2 Contention Resolution ....................................... 10 4 Notification ................................................ 10 4.1 Acceptable Label Set Object ................................. 10 4.2 Notify Request Objects ...................................... 11 4.3 Notify Message .............................................. 12 4.4 Removing State with a PathErr message ....................... 14 5 Explicit Label Control ...................................... 15 5.1 Label ERO subobject ......................................... 15 @@ -81,71 +71,65 @@ 9 Fault Handling .............................................. 25 9.1 Restart_Cap Object .......................................... 26 9.2 Processing of Restart_Cap Object ............................ 27 9.3 Modification to Hello Processing to Support State Recovery .. 27 9.4 Control Channel Faults ...................................... 28 9.5 Nodal Faults ................................................ 28 10 RSVP Message Formats and Handling ........................... 31 10.1 RSVP Message Formats ........................................ 31 10.2 Addressing Path and PathTear Messages ...................... 33 11 Acknowledgments ............................................. 33 -12 Security Considerations ..................................... 33 +12 Security Considerations ..................................... 34 13 IANA Considerations ......................................... 34 13.1 IANA [Suggestions /] Assignments ............................ 35 -14 References .................................................. 36 -14.1 Normative References ........................................ 37 -14.2 Informative References ...................................... 37 -15 Authors' Addresses .......................................... 38 - -[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 Fixed indication of infinite restart time -o Added IANA [Suggestions /] Assignments Section -o Split references section -o Minor editorial changes and clarifications +14 Intellectual Property Considerations ........................ 37 +15 References .................................................. 37 +15.1 Normative References ........................................ 37 +15.2 Informative References ...................................... 38 +16 Contributors ................................................ 38 +17 Contact Address ............................................. 41 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 specific formats and mechanisms needed to support all four classes of - interfaces. CR-LDP extensions can be found in [GMPLS-LDP]. + interfaces. [GMPLS-SIG] should be viewed as a companion document to this document. The format of this document parallels [GMPLS-SIG]. In addition to the other features of Generalized MPLS, this document also defines RSVP-TE specific features to support rapid failure notification, see Sections 4.2 and 4.3. 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]. 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 Object - A Path 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 object 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 Path 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 object 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 object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (19)|C-Type (4)[TBA]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -188,59 +171,60 @@ 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. When an error message is not generated, normal processing occurs. In the transit case this will typically result in a Path message being propagated. In the egress case and PHP special case this will typically result in a Resv message being generated. -2.1.2. Bandwidth Encoding +2.2. Bandwidth Encoding Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC objects. See [GMPLS-SIG] for a definition of values to be used for specific signal types. These values are set in the Peak Data Rate - field of Int-Serv objects. Other bandwidth/service related - parameters in the object are ignored and carried transparently. + field of Int-Serv objects, see [RFC2210]. Other bandwidth/service + related parameters in the object are ignored and carried + transparently. -2.2. Generalized Label Object +2.3. Generalized Label Object The format of a Generalized Label object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters and encoding of labels. -2.2.1. Procedures +2.3.1. Procedures The Generalized Label travels in the upstream direction in Resv messages. The presence of both a generalized and normal label object in a Resv message is a protocol error and should treated as a malformed message by the recipient. The recipient of a Resv message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication. -2.3. Waveband Switching +2.4. Waveband Switching Waveband switching uses the same format as the generalized label, see section 2.2. Waveband Label uses C-Type (3), In the context of waveband switching, the generalized label 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -248,58 +232,58 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Waveband Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. -2.3.1. Procedures +2.4.1. Procedures The procedures defined in Section 2.2.1 apply to waveband switching. This includes generating a ResvErr message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable. Additionally, when a waveband is switched to another waveband, it is possible that the wavelengths within the waveband will be mirrored about a center frequency. When this type of switching is employed, the start and end label in the waveband label object MUST be flipped before forwarding the label object with the new waveband Id. In this manner an egress/ingress LSR which receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths. This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established. -2.4. Suggested Label +2.5. Suggested Label The format of a Suggested_Label object is identical to a generalized label. It is used in Path messages. A Suggested_Label object uses Class-Number TBA (of form 10bbbbbb) and the C-Type of the label being suggested. Errors in received Suggested_Label objects MUST be ignored. This includes any received inconsistent or unacceptable values. Per [GMPLS-SIG], if a downstream node passes a label value that differs from the suggested label upstream, the upstream LSR MUST either reconfigure itself so that it uses the label specified by the downstream node or generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream. -2.5. Label Set +2.6. Label Set The Label_Set object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of 1. It is used in Path messages. The format of a Label_Set 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(TBA)| C-Type (1) | @@ -316,21 +300,21 @@ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label Type: 14 bits Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate Label object. Only the low order 8 bits are used in this field. See [GMPLS-SIG] for a description of other parameters. -2.5.1. Procedures +2.6.1. Procedures A Label Set is defined via one or more Label_Set objects. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) objects respectively. When the Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable. The absence of any Label_Set objects implies that all labels are @@ -428,25 +412,25 @@ extension, the Notify Request object, identifies where event notifications are to be sent. The third extension, the Notify message, provides for general event notification.) The final notification related extension allows for the removal of Path state on handling of PathErr messages. 4.1. Acceptable Label Set Object Acceptable_Label_Set objects use a Class-Number TBA (of form 10bbbbbb). The remaining contents of the object, including C-Type, - have the identical format as the Label_Set object, see Section 2.5. + have the identical format as the Label_Set object, see Section 2.6. Acceptable_Label_Set objects may be carried in PathErr and ResvErr messages. The procedures for defining an Acceptable Label Set follow - the procedures for defining a Label Set, see Section 2.5.1. + the procedures for defining a Label Set, see Section 2.6.1. Specifically, an Acceptable Label Set is defined via one or more Acceptable_Label_Set objects. Specific labels/subchannels can be added to or excluded from an Acceptable Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Label Set via Action two (2) and three (3) objects respectively. When the Acceptable_Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable. The inclusion of Acceptable_Label_Set objects is optional. If @@ -526,25 +510,25 @@ The Notify message provides a mechanism to inform non-adjacent nodes of LSP related events. Notify messages are normally generated only after a Notify Request object has been received. The Notify message differs from the currently defined error messages (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify - message to the target node, similar to ResvConf processing in [RSVP]; - or (b) encapsulated in a new IP header whose destination is equal to - the target IP address. Regardless of the transmission mechanism, - nodes receiving a Notify message not destined to the node forward the - message, unmodified, towards the target. + message to the target node, similar to ResvConf processing in + [RFC2205]; or (b) encapsulated in a new IP header whose destination + is equal to the target IP address. Regardless of the transmission + mechanism, nodes receiving a Notify message not destined to the node + forward the message, unmodified, towards the target. To support reliable delivery of the Notify message, an Ack Message [RFC2961] is used to acknowledge the receipt of a Notify Message. See [RFC2961] for details on reliable RSVP message delivery. 4.3.1. Required Information The Notify message is a generalized notification message. The IP destination address is set to the IP address of the intended receiver. The Notify message is sent without the router alert @@ -649,21 +633,21 @@ an error with the Path_State_Removed flag set to zero MUST NOT set this flag unless it also generates a corresponding PathTear message. Note that the use of this flag does not result in any interoperability incompatibilities. 5. Explicit Label Control The Label ERO and RRO subobjects are defined to support Explicit Label Control. Note that the Label RRO subobject was defined in - [RFC3209] and is being revised to support bidirectional LSPs. + [RFC3209] and is being extended to support bidirectional LSPs. 5.1. Label ERO subobject The Label ERO subobject is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |U| Reserved | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -688,21 +672,21 @@ 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. 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 + containing an IP address, or an 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 @@ -1015,27 +999,29 @@ 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 - error code "Routing Error" and error value of "Bad Explicit Route - Object" toward the sender. + Note, the node originating an IF_ID object MUST ensure that the + selected outgoing interface, as specified in the IF_ID object, is + consistent with an 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 Message with the error code "Routing Error" and error + value of "Bad Explicit Route Object" toward the sender. This check + CANNOT be performed when the initial ERO subobject is not the + incoming interface. 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 ERROR_SPEC Objects are defined. 8.2.1. IF_ID ERROR_SPEC Objects The format of the IPv4 IF_ID ERROR_SPEC Object is: @@ -1067,21 +1053,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Error Code | Error Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [RFC2205] for a description of address, flags, error code and error value fields. See [GMPLS-SIG] for a description of - parameters and encoding of TLVs.n + parameters and encoding of TLVs. 8.2.2. Procedures Nodes wishing to indicate that an error is related to a specific interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects SHOULD be generated and processed as any other ERROR_SPEC Object, see [RFC2205]. 9. Fault Handling @@ -1149,22 +1135,23 @@ When a node receives a Hello message with the Restart_Cap object, it SHOULD record the values of the parameters received. 9.3. Modification to Hello Processing to Support State Recovery When a node determines that RSVP communication with a neighbor has been lost, and the node previously learned that the neighbor supports state recovery, the node SHOULD wait at least the amount of time indicated by the Restart Time indicated by the neighbor before - invoking procedures related to communication loss. A node MAY wait - longer based on local policy or configuration information. + invoking procedures related to communication loss. A node MAY wait a + different amount of time based on local policy or configuration + information. During this waiting period, all Hello messages MUST be sent with a Dst_Instance value set to zero (0), and Src_Instance should be unchanged. While waiting, the node SHOULD also preserve the RSVP and MPLS forwarding state for (already) established LSPs that traverse the link(s) between the node and the neighbor. In a sense with respect to established LSPs the node behaves as if it continues to receive periodic RSVP refresh messages from the neighbor. The node MAY clear RSVP and forwarding state for the LSPs that are in the process of being established when their refresh timers expire. @@ -1575,82 +1560,106 @@ o "Routing problem/Label Set" (Suggested value =11) o "Routing problem/Switching Type" (Suggested value =12) (duplicate code 13 dropped) o "Routing problem/Unsupported Encoding" (Suggested value =14) o "Routing problem/Unsupported Link Protection" (Suggested value =15) o "Notify Error/Control Channel Active State" (Suggested value =4) o "Notify Error/Control Channel Degraded State" (Suggested value =5) --------------------------------------------------------------------- -14. References +14. Intellectual Property Considerations -14.1. Normative References + This section is taken from Section 10.4 of [RFC2026]. -[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links - in RSVP-TE", Internet Draft, - draft-ietf-mpls-rsvp-unnum-02.txt, August 2001 + 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. + +15. References + +15.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. + +[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links + in RSVP-TE", Internet Draft, + draft-ietf-mpls-rsvp-unnum-07.txt, July 2002. [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. +[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services," RFC 2210, September 1997. + [RFC2961] Berger, L. et al, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001 [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. -14.2. Informative References +15.2. Informative References [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. -[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - - CR-LDP Extensions", Internet Draft, - draft-ietf-mpls-generalized-cr-ldp-06.txt, - April 2002. - [PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE", Internet Draft, draft-pan-rsvp-te-restart-01.txt, July 2001. +[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. -15. Authors' Addresses +16. 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 @@ -1690,24 +1699,25 @@ 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 Ping Pan - Juniper Networks - 1194 N.Mathilda Ave - Sunnyvale, CA 94089 - Email: pingpan@juniper.net + Ciena + 10480 Ridgeview Court + Cupertino, CA 95014 + Phone: 408-366-4700 + Email: ppan@ciena.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 @@ -1738,11 +1748,21 @@ 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:57:53 2002 +17. Contact Address + + 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:33 2002