CCAMP Working Group Z. Ali (Cisco) Internet Draft A. Farrel (Old Dog Consulting) Category: Standards Track D. Papadimitriou (Alcatel) A. Satyanarayana (Movaz) A. Zamfir (Cisco) Expires: November 2004 May 2004 Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE signaling using Bundled Traffic Engineering (TE) Links draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) RSVP-TE signaling. It extends the TLV definitions of [RFC3471] to provide the means to identify component links of unnumbered link bundles within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects. It also defines the extensions to GMPLS RSVP-TE in support of component link identifiers for explicit resource control and recording over link bundles. D.Papadimitriou (Editor) et al. 1 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 1. Motivation Link bundling introduced in [BUNDLE] is used to improve routing scalability by reducing the amount of Traffic Engineering related information that needs to be flooded and handled by an IGP within an Autonomous System. This is accomplished by aggregating and abstracting the TE Link resource. GMPLS RSVP-TE [RFC3471, RFC3473] allows a bundle of Traffic Engineering links (TE links) to be represented as a single TE link bundle (a.k.a. bundled TE link). The constituting links of a TE link bundle are referred to as component TE links or simply component links. [RFC3477] defines how unnumbered links may be used in RSVP-TE. [RFC3471] and [RFC3473] define how unnumbered links can be identified within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects. Both numbered and unnumbered component link identifiers are supported. Moreover, [RFC3471] and [RFC3473] define how numbered and unnumbered component links of numbered TE link bundles may be identified within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects. However, there is no provision for identifying component links of unnumbered TE link bundles within the IF_ID RSVP_HOP and IF_ID ERROR_SPEC objects. This is required for completeness and to allow full functionality of GMPLS RSVP-TE. This document extends the TLV definitions of [RFC3471] to provide the means to identify component links of unnumbered TE link bundles within the IF_ID_RSVP_HOP and IF_ID ERROR_SPEC objects. GMPLS RSVP-TE [RFC3471, RFC3473] recognizes the value of specifying the link (interface) identifier both during LSP establishment for out-of-band signaling (IF_ID_RSVP_HOP object), and for error reporting (IF_ID ERROR_SPEC object). This is achieved using TLVs in these objects to specify the link (interface) identifier. Both numbered and unnumbered link (interface) identifiers are supported. Furthermore, GMPLS RSVP-TE [RFC3471, RFC3473] recognizes the value of specifying the component link (interface) identifier of a TE link bundle during LSP establishment (IF_ID_RSVP_HOP object), and for error reporting (IF_ID ERROR_SPEC object). This is achieved using TLVs in these objects to specify the component link (interface) identifier within a TE link (interface) identifier. However, only numbered and unnumbered component link (interface) identification within numbered TE link bundles is supported. In (G)MPLS, resource control and recording is performed by the use of an explicit route, i.e., EXPLICIT_ROUTE Object (ERO) and RECORD_ROUTE Object (RRO), respectively. In most scenarios the complete resource identification is left as a local decision. However, there are cases when it is desirable for a non-local (e.g., LSP Head-end) node to identify completely or partially the LSP resources. Consequently, Label ERO (EXPLICIT_ROUTE Object) and RRO (RECORD_ROUTE Object) subobjects are defined in [RFC3473] to support Explicit Label Control and recording. When link bundling is used to aggregate multiple component links into a TE link bundle, the label is not the only resource that needs D.Papadimitriou (Editor) 2 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 to be identified and recorded. In other words, the TE link bundle identifier and the label value specified in the ERO/RRO objects are not enough to completely identify the resource. For the bundled TE link case, in order to fully specify the resources on a TE link bundle for a given LSP, the component link identifier needs to be specified along with the label. In the case of bi-directional LSPs both upstream and downstream information may be specified. Therefore, explicit resource control and recording over a TE link bundle also requires ability to specify a component link within the TE link bundle. This document defines extensions to and describes the use of RSVP-TE [RFC3209], [RFC3471], [RFC3473], and [RFC3477] to specify the component link identifier for resource recording and explicit resource control over TE link bundles. Specifically, it defines the component interface identifier ERO and RRO subobjects to complement their Label ERO and RRO counterparts. Furthermore, procedures for processing component interface identifier ERO and RRO subobjects and how they can co-exist with the Label ERO and RRO subobjects are specified. The document also addresses identification of numbered and unnumbered component link (interface) within unnumbered TE link bundles. 2. Conventions used in this document: 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]. Moreover, the reader is assumed to be familiar with the terminology introduced in [GMPLS-ARCH], [RFC3471], [RFC3473], [RFC3477] and [BUNDLE]. The following abbreviations are used in this document: 3. Unbundled TE Link Identification TE links need to be identified in ERO, RRO, RSVP_HOP and ERROR_SPEC objects. When out-of-band signaling is used, [RFC3471] extends RSVP_HOP and ERROR_SPEC objects, to include TLVs to completely identify the TE links. These are the IF_ID RSVP_HOP and IF_ID ERROR_SPEC objects. A numbered unbundled TE link can be uniquely identified with the IPv4 address or the IPv6 address of the TE link. There are no additional formats required to those defined in [RFC3209] to identify numbered unbundled TE links in ERO and RRO objects. The IPv4 and IPv6 TLVs defined in [RFC3471] are used with IF_ID RSVP_HOP and IF_ID ERROR_SPEC objects to identify numbered unbundled TE links when out-of-band signaling is used. An unnumbered unbundled TE link can be uniquely identified by the tuple {IP Address, Interface ID}. [RFC3477] defines the Unnumbered Interface ID subobject to identify unnumbered unbundled TE links in ERO and RRO objects. The IF_INDEX TLV defined in [RFC3471] is used with the IF_ID RSVP_HOP and the IF_ID ERROR_SPEC objects to D.Papadimitriou (Editor) 3 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 identify unnumbered unbundled TE links when out-of-band signaling is used. The following are the TLVs are defined in [RFC3471] to identify unbundled TE links. Type Length Format Description ---- ------ --------- ----------- 1 8 IPv4 Address IPv4 (Interface address) 2 20 IPv6 Address IPv6 (Interface address) 3 12 Compound IF_INDEX (Interface index) 4. Component and Bundled TE Link Identification If a TE link bundle is numbered, the tuple {IP Address, Component ID} is required to uniquely identify a component link in the TE link bundle. In this case, depending on the origin of value assigned to the IP Address either the tuple {Router Address, Component ID} or {TE Link Address, Component ID} is sufficient to uniquely identify an unnumbered component link in the TE link bundle. These tuples are respectively of Type 4, 5 and the newly defined Type 6, 7. [RFC3471] defines the following TLVs for Component ID identification IF_ID RSVP_HOP and IF_ID ERROR_SPEC objects. Type Length Format Description ---- ------ ------ ----------- 4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface) 5 12 Compound COMPONENT_IF_UPSTREAM (Component interface) 6 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface) 7 12 Compound COMPONENT_IF_UPSTREAM (Component interface) If a TE link bundle is unnumbered, the tuple {IP Address, Bundle ID, Component ID} is required to uniquely identify a component link in the TE link bundle. In this case, two new TLVs are defined for use in the IF_ID RSVP_HOP object and in the IF_ID ERROR_SPEC Object to identify a component link in an unnumbered TE link bundle. Note that the Type values shown here are only suggested values - final values are TBD and to be determined by IETF consensus. Type Length Format Description ---- ------ ------ ----------- 8 16 See below UNUM_COMPONENT_IF_DOWN (Component interface) 9 16 See below UNUM_COMPONENT_IF_UP (Component interface) The formats of both the TLVs are the same, as defined below. Two new TLV types are defined. UNUM_COMPONENT_IF_DOWN is used to identify the downstream component link in an unnumbered TE link bundle. UNUM_COMPONENT_IF_UP is used to identify the upstream component link in an unnumbered TE link bundle. Note: [BUNDLE] and [RFC3477] assumes that identifying component link suffices to identify (bundle link, component link) for both D.Papadimitriou (Editor) 4 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 numbered and unnumbered case. I.e., for unnumbered case, both component link identifiers and TE link identifiers comes from the same unit32 bit space. 4.1 TLV Definitions The new TLVs have a common format as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Address: 32 bits Any IP address associated with the local node. This should be an IP address that has the highest availability on the node. This may match the Router Address value as advertised in TE LSAs by routing. Interface ID: 32 bits The identifier of the unnumbered bundled link. By definition, this is unique within the scope of the node identified by the IP Address field. Component ID: 32 bits The identifier of the component link in the unnumbered TE bundle, uniquely identified by the tuple {IP Address, Interface ID}. During LSP establishment, the special value 0xFFFFFFFF can be used to indicate the same label to be valid across all component links in the bundle identified by the {IP Address, Interface ID}. 5. Signaling Component TE Links in ERO A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used to specify component interface identifier of a bundled TE Link. This subobject SHOULD NOT be used apart from (explicit) egress label control as defined in [EGRESS]. This subobject has the following format: Component Interface Identifier ERO subobject 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 D.Papadimitriou (Editor) 5 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |U| Reserved (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // IPv4, IPv6 or unnumbered Component Interface Identifier // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L: 1 bit This bit must be set to 0. Type: 10 (TBD) Component Interface identifier IPv4 11 (TBD) Component Interface identifier IPv6 12 (TBD) Component Interface identifier Unnumbered Length: The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is 8 bytes for the Component Interface identifier types: IPv4 and Component Interface identifier Unnumbered. For Component Interface identifier IPv6 type of sub-object, the length field is 20 bytes. U: 1 bit This bit indicates the direction of the component interface. It is 0 for the downstream interface. It is set to 1 for the upstream interface and is only used for bi- directional LSPs. 5.1 Processing of Component Interface Identifier ERO Subobject The Component Interface Identifier ERO subobject identifies the component of a bundled TE Link. This subobject MUST follow a subobject containing the IP address, or the link identifier [RFC3477], associated with the TE link on which it is to be used. It is used to. The following SHOULD result in "Bad EXPLICIT_ROUTE object" error being sent upstream by a node processing an ERO that contains the Component Interface ID sub-object: o) The first component interface identifier subobject is not preceded by a sub-object containing an IPv4 or IPv6 address, or an interface identifier [RFC3477], associated with a TE link. o) The Component Interface Identifier ERO subobject follows a subobject that has the L-bit set. o) On unidirectional LSP setup, there is a Component Interface Identifier ERO subobject with the U-bit set. D.Papadimitriou (Editor) 6 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 o) Two Component Interface Identifier ERO subobjects with the same U-bit values exist. If a node implements the component interface identifier subobject, it must check if it represents a component interface in the bundled TE Link specified in the preceding subobject that contains the IP address or interface identifier of the TE Link. If the content of the component interface identifier subobject does not match a component interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD be reported as "Routing Problem" (error code 24). If the U-bit of the subobject being examined is cleared (0) and the upstream interface specified in this subobject is acceptable, then the value of the upstream component interface is copied in the TLV of the IF_ID HOP object [RFC 3471]. In this case, the local decision normally used to select the upstream component link is bypassed. If this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be reported as "Routing Problem" (error code 24). If the U-bit of the subobject being examined is set (1), then the value represents the component interface to be used for upstream traffic associated with the bidirectional LSP. Again, if this interface is not acceptable or if the request is not one for a bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be reported as "Routing Problem" (error code 24). Otherwise, the component interface IP address/ identifier is copied into a TLV sub- object as part of the IF_ID RSVP_HOP object. The IF_ID RSVP_HOP object constructed as above MUST be included in the corresponding outgoing Path message. Note that, associated with a TE Link sub-object in the ERO, either the upstream component interface or the downstream component interface or both may be specified. As specified in [BUNDLE] there is no relationship between the TE Link type (numbered or unnumbered) and the Link type of any one of its components. The component interface identifier ERO subobject is OPTIONAL. Furthermore, component interface identifier ERO subobject and Label ERO subobject (see [RFC 3471] and [RFC 3473]) may be included in the ERO independently of each other. One of the following alternatives applies: o) When both sub-objects are absent, a node may select any appropriate component link within the TE link and any label on the selected component link. o) When the Label subobject is only present for a bundled link, then the selection of the component link within the bundle is a local decision and the node may select any appropriate component link, which can assume the label specified in the Label ERO. o) When only the component interface identifier ERO subobject is present, a node MUST select the component interface specified in the ERO and may select any appropriate label value at the specified component link. o) When both component interface identifier ERO subobject and Label D.Papadimitriou (Editor) 7 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 ERO subobject are present, the node MUST select the specified component link and the specified label value on that component link. When present, both subobjects may appear in any relative order to each other but they MUST appear after the TE Link sub- object that they refer to. After processing, the component interface identifier subobjects are removed from the ERO. Inferred from above, the interface subobject should never be the first subobject in a newly received message. If the component interface subobject is the first subobject in a received ERO, then it SHOULD be treated as a "Bad strict node" error. Note: Information to construct the Component Interface ERO subobject may come from the same mean used to populate the label ERO subobject. Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Component Interface subobject are outside the scope of this document. 6. Signaling Component TE Links in (IF_ID)_RSVP_HOP object This memo does not modify procedures for use of TLVs in the IF_ID RSVP_HOP object, defined in [RFC3471], [RFC3473] and [RFC3477]. The new TLVs can be used in the IF_ID RSVP_HOP object. The component ID values in TLV types 6 and 7 are values local to the upstream node. TLV type 6 is used with semantics similar to TLV type 4. TLV type 7 is used with semantics similar to TLV type 5. When a component link part of a bundled TE Link fails and the LSP traffic is "automatically" moved to another component link. This must be followed not only by an IGP update on available resources for the bundle but also by a soft state resync at the two ends of the bundle (new states are on different interfaces, ideally without doing any "local" make-before-break i.e. no PathErr message exchange). Need to clearly differentiate this from span protection where a single link or component link includes physical protection. In the former case, the upstream node would change the IF_ID information for the LSP on the new Path it sends and the downstream node would update forwarding and protocol state. There would be no impact further up or downstream (unless component link recording was enabled in the RRO). 7. Reporting Component TE Links in RROs A new OPTIONAL subobject of the Record Route Object (RRO) is used to record component interface identifier of a (bundled) TE Link. This subobject has the following format: Component Interface Identifier RRO subobject 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.Papadimitriou (Editor) 8 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 |L| Type | Length |U| Reserved (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // IPv4, IPv6 or unnumbered Component Interface Identifier // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L: 1 bit This bit must be set to 0. Type: 10 (TBD) Component Interface identifier IPv4 11 (TBD) Component Interface identifier IPv6 12 (TBD) Component Interface identifier Unnumbered Length: The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is 8 bytes for the Component Interface identifier IPv4 and Component Interface identifier Unnumbered types. For Component Interface identifier IPv6 type of sub-object, the length field is 20 bytes. U: 1 bit This bit indicates the direction of the component interface. It is 0 for the downstream interface. It is set to 1 for the upstream interface and is only used for bi- directional LSPs. 7.1 Processing of Component Interface identifier RRO Subobject If a node desires component link recording, the "Component Link Recording desired" flag (value TBD) should be set in the LSP_ATTRIBUTES object, object that is defined in [RSVP-TE- ATTRIBUTE]. Another alternate is to use an available flag in the SESSION_ATTRIBUTE object [RFC3209]. The later makes the component link recording request similar to the label recording request. These alternatives need to be discussed with the CCAMP working group and close accordingly. Setting of "Component Link Recording desired" flag is independent of the Label Recording flag in SESSION_ATTRIBUTE object as specified in [RFC3209]. Nevertheless, the following combinations are valid: 1) If both Label and Component Link flags are clear, then neither Labels nor Component Links are recorded. 2) If Label Recording flag is set and Component Link flag is clear, then only Label Recording is performed as defined in [RFC3209]. 3) If Label Recording flag is clear and Component Link flag is set, then Component Link Recording is performed as defined in this proposal. D.Papadimitriou (Editor) 9 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 4) If both Label Recording and Component Link flags are set, then Label Recording is performed as defined in [RFC3209] and also Component Link recording is performed as defined in this proposal. In most cases a node initiates recording for a given LSP by adding the RRO to the Path message. If the node desires Component Link recording and if the outgoing TE link is bundled, then the initial RRO contains the Component Link identifier (numbered or unnumbered) as selected by the sender. As well, the "Component Link Recording desired" flag is set in the LSP_ATTRIBUTE object. If the node also desires label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object. When a Path message with the "Component Link Recording desired" flag set is received by an intermediate node, if a new Path message is to be sent for a downstream bundled TE link, the node adds a new Component Link subobject to the RRO and appends the resulting RRO to the Path message before transmission. Note that, unlike Labels, Component Link identifiers are always known on receipt of the Path message. When the destination node of an RSVP session receives a Path message with an RRO and the "Component Link Recording desired" flag set, this indicates that the sender node needs TE route as well as component link recording. The destination node initiates the RRO process by adding an RRO to Resv messages. The processing mirrors that of the Path messages The Component Interface Record subobject is pushed onto the RECORD_ROUTE object prior to pushing on the node's IP address. A node MUST NOT push on a Component Interface Record subobject without also pushing on the IP address or unnumbered Interface Id subobject that identifies the TE Link. When component interfaces are recorded for bi-directional LSPs, component interface RRO subobjects for both downstream and upstream interfaces MUST be included. 8. Backward Compatibility Issues TBD. 9. Security Considerations This draft introduces no new security considerations to either [RFC3473] or [RFC3477]. GMPLS security is described in section 11 of [RFC3471] and refers to [RFC3209] for RSVP-TE. 10. IANA Considerations IF_ID TLV type values are not currently tracked or managed by IANA. This might be a good opportunity to move them under IANA control. D.Papadimitriou (Editor) 10 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 This document defines the following: 1. Subobjects of the EXPLICIT_ROUTE object (C-Type 1): - Component Interface identifier IPv4 10 (TBA) - Component Interface identifier IPv6 11 (TBA) - Component Interface identifier Unnumbered 12 (TBA) 2. Subobjects of the RECORD_ROUTE object (C-Type 1): - Component Interface identifier IPv4 10 (TBA) - Component Interface identifier IPv6 11 (TBA) - Component Interface identifier Unnumbered 12 (TBA) 3. LSP Attributes Flag Registry value (if not included in the SESSION_ATTRIBUT object flags) - Component Link Recording desired 7 (TBA) 11. Intellectual Property Consideration The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 12.1 IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 13. Acknowledgments This document is the work of numerous authors and consists of a composition of a number of previous documents in this area, including: D.Papadimitriou (Editor) 11 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 draft-farrel-ccamp-ifid-unnum-00.txt draft-zamfir-explicit-resource-control-bundle-03.txt 14. References 14.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. [RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [RFC3471] Berger, L. (Editor) et al., "Generalized Multi- Protocol Label Switching (GMPLS) Signaling - Functional Description," RFC 3471, January 2003. [RFC3473] Berger, L. (Editor) et al., "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC 3473, January 2003. [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in RSVP-TE", RFC 3477, January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 14.2 Informative References [CRANKBACK] Farrel, A. (Editor), "Crankback Signaling Extensions for MPLS Signaling", Internet Draft (work in progress), draft-ietf-ccamp-crankback-01.txt, January 2004. [GMPLS-ARCH]Mannie, E. (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture," Internet Draft (work in progress), draft-ietf-ccamp-gmpls- architecture-07.txt, May 2003. [GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in Support of Generalized MPLS," Internet Draft (work in progress), draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. D.Papadimitriou (Editor) 12 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 [IF-ID] Farrel, A. et al., "Identification of Component Links of Unnumbered Interfaces," Internet Draft (work in progress), draft-farrel-ccamp-ifid-unnum-00.txt, February 2004. [ERC] Zamfir, A. et al., "Component Link Recording and Resource Control for GMPLS Link Bundles," Internet Draft (work in progress), draft-zamfir-explicit- resource-control-bundle-03.txt, February 2004. 15. Authors Addresses Zafar Ali Cisco Systems Inc. 100 South Main St. #200 Ann Arbor, MI 48104, USA Phone: (734) 276-2459 Email: zali@cisco.com Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk Dimitri Papadimitriou (Editor) Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Arun Satyanarayana Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102, USA Phone: +1 703 847-1785 EMail: aruns@movaz.com Anca Zamfir Cisco Systems Inc. 2000 Innovation Dr., Kanata, Ontario, K2K 3E8, Canada Phone: (613)-254-3484 EMail: ancaz@cisco.com D.Papadimitriou (Editor) 13 draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt May 2004 Full Copyright Statement "Copyright (C) The Internet Society (date). 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." D.Papadimitriou (Editor) 14