Network work group Fatai Zhang Internet Draft Dan Li Intended status: Standards Track Jianhua Gao Expires: September 2009 Huawei March 02, 2009 RSVP-TE extensions to GMPLS Calls draft-zhang-ccamp-gmpls-call-extensions-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 02, 2009. Abstract Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. Expires September 02, 2009 [Page 1] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain case). This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit nodes (besides the Call-initiator and Call-terminator) are involved in these Calls. 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 RFC-2119 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. Motivation...................................................3 3. Solution.....................................................5 4. Operations...................................................8 4.1. User-Initiated Calls....................................8 5. Security Considerations......................................9 6. Manageability Considerations.................................9 7. IANA Considerations..........................................9 7.1. Call_ERO Object.........................................9 7.2. Call_RRO Object........................................10 7.3. RSVP Error Codes and Error Values......................10 8. Normative References........................................10 9. Authors' Addresses..........................................12 Acknowledgment.................................................12 1. Introduction The concept of a Generalized Multi-Protocol Label Switching (GMPLS) Call is introduced in [RFC4974]. A Call is an association between endpoints and possibly between key transit points (such as network boundaries) in support of an instance of a service. The requirements of Calls and the RSVT-TE extensions in support of Calls are also described in [RFC4974]. A Call is usually established between end-points to verify polices and authorization applied on these end-points. However, in a multi- domain environment, some key polices and authorization are usually Zhang Expires September 01, 2009 [Page 2] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 deployed on the corresponding domain border nodes (domain ingress or egress nodes), so these border nodes are also involved in processing the Call when the Call is going through these domains. These nodes that process the Call are known as "Call Managers". Although it is stated that the mechanisms proposed in [RFC4974] are applicable to any environment (including multi-area), the "Call Path" is determined hop-by-hop by each Call Manager in sequence along the path of the Call. That is, each Call Manager forwards the Notify message that is used to manage the Call to the next Call Manager along the Call Path. The Notify messages are targeted at (i.e., carry the IP address of) the next Call Manager, and the route that the messages follow through the network to reach the next Call Manager is not important. However, it is desirable to allow the Call-initiator to determine the Call Path and to signal it explicitly in some cases (especially in the multi-domain case). This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit Call Managers (besides the Call-initiator and Call-terminator) are involved in a Call. Note that Call and Connection are separated in the signaling, and Call procedures do not impact the Connection procedures, so this document does not modify any Connection procedures defined in [RFC3471], [RFC3473], [RFC4208], and other existing protocol family. 2. Motivation In some cases, it is desirable to set up a Call through not only the Call-initiator and Call-terminator, but also some transit Call Manager nodes (e.g., transit border domain nodes) to verify the corresponding polices and authorization applied on these nodes. For instance, in the multi-domain case as shown in Figure 1, there are three interconnected domains. Nodes I, D11, and D12 are in Domain 1, and the nodes D11 and D12 are the border nodes. Nodes D21, D22, D23, and D24 are the border nodes of Domain 2, and the internal nodes of Domain 2 are not shown in the figure. Nodes D31, D32, and E are in Domain 3, and the nodes D31 and D32 are the border nodes. Policies and authorization are often applied in domain border nodes, such as the nodes D11, D12, D21, D22, D23, D24, D31, and D32 in this example. Therefore, in this case, when a Call between Call-initiator (node I) and Call-terminator (node E) is going to be setup, the Call Zhang Expires September 01, 2009 [Page 3] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 should be processed in some domain border nodes (for example, the nodes D11, D21, D23, D31 should process the Call when the Call Path I-D11-D21-D23-D31-E is selected). Note that in this case, there may be several alternative Call Paths between Call-initiator and Call-terminator. For example, in the Figure 1, the possible Call paths may be I-D11-D21-D23-D31-E or I- D12-D22-D24-D32-E, or some other path depending on the interconnectivity across the domains. +------------------+ +----------------+ +-----------------+ | +--+ | | +--+ +--+ | | +--+ | | --| |--|--|--| |----| |--|--|--| |-- | | / | | | | | | | | | | | | \ | | / +--+ | | +--+ +--+ | | +--+ \ | | +--+ / D11 | | D21 D23 | | D31 \ +--+ | | | |- | | | | -| | | | | |- | | | | -| | | | +--+ \ +--+ | | +--+ +--+ | | +--+ / +--+ | | I \ | | | | | | | | | | | | / E | | ---| |--|--|--| |----| |--|--|--| |--- | | +--+ | | +--+ +--+ | | +--+ | | D12 | | D22 D24 | | D32 | | | | | | | +------------------+ +----------------+ +-----------------+ Domain1 Domain2 Domain3 Figure 1: Multi-domain Scenario Note that how to determine the Call Path is out of the scope of this document. According to the Section 7.3.1 of [RFC 4974], it is already supported that the third parties (i.e., non-end points such as External Call Managers) are involved in the Call, but there is no mechanisms for the Call-initiator to control the Call Path. The Call Path is determined by each Call Manager in turn selecting the next Call Manager on the path to the Call-terminator and forwarding the Notify message that sets up the Call. However, in the case of a multi-domain Call, commercial and policy motivations normally play a role in selecting the Call Path. This selection may be at a coarse level (for example, identifying which domains should or should not be used), or may be at a finer level (for example, identifying which Call Managers to use). Note that there is no concept of specifying links or resources within the Call Zhang Expires September 01, 2009 [Page 4] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 Path as the Call is an ordered association of Call Managers, and not a data path in the network. Therefore, it is desirable to allow full control for the Call- initiator, which means that the Call-initiator can identify the full Call Path explicitly. Moreover, the management plane needs to be able to identify the Call Path explicitly as an instruction to the Call- initiator. This document defines protocol extensions that provide a solution for these requirements. 3. Solution In order to identify the Call Path explicitly for the Call-initiator, the CALL_EXPLICIT_ROUTE object (Call_ERO) is introduced. The format of the Call_ERO is defined as follows: Class = TBD (0bbbbbbb), C_Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Call_ERO is the same as EXPLICIT_ROUTE object (ERO) described in [RFC3209]. And the subobjects including IPv4 prefix, IPv6 prefix, and autonomous system number defined in [RFC3209] could be reused as subobjects of Call_ERO. In inter-domain environment, it is possible to collect and communicate information about the inter-domain links because the domains usually don't share the Traffic Engineering (TE) information between domains. So Call_RRO and its Link_Capability subobject are introduced to record this information. The format of the Call_RRO is defined as follows: Class = TBD (11bbbbbb), C_Type = 1 Zhang Expires September 01, 2009 [Page 5] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Call_RRO is the same as RECORD_ROUTE object (RRO) described in [RFC3209]. The subobjects of RRO including IPv4 address and IPv6 address defined in [RFC3209] could be reused as subobjects of Call_RRO and the formats of the subobjects for LINK_CAPABILITY object [RFC4974] including type 1, type 2, type 4, type 64 and type 65 could be reused as Link_Capability subobjects of Call_RRO (Note that the corresponding types are redefined as type 3, type 4, type 5, type 64 and type 65). The following subobjects are defined currently: - Type 1: IPv4 address subobject defined in Section 4.4.1.1 of [RFC3209]. - Type 2: IPv6 address subobject defined in Section 4.4.1.2 of [RFC3209]. - Type 3: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209]. - Type 4: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209]. - Type 5: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477]. - Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]). - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]). Zhang Expires September 01, 2009 [Page 6] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 Similar to the Label RRO [RFC3209], the Link_Capability subobjects are pushed onto the Call_RRO object prior to pushing on the IPv4 or IPV6 subobject. A Call Manager MUST NOT push on a Link_Capability subobject without also pushing on an IPv4 or IPv6 subobject. Note that multiple Link_Capability subobjects following IPv4 or IPv6 subobject can be presented in the Call_RRO to collect all the possible link information between domains. The revised Notify message is as follows using the meta-language described in [RBNF]: ::= [ ] [[ | ]...] [ ] Where ::= [ ] ::= [ ] [ ...] [ ] [ ] [ ] [ ] [ | ] And where: ::= see [RFC3473] ::= see [RFC3473] Zhang Expires September 01, 2009 [Page 7] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 4. Operations The processes for the revised Notify message comply with the procedures described in [RFC3974] except that the Call_ERO is processed at the Call Managers. The processes for the Call_ERO and Call_RRO are similar to the Connection ERO and RRO [RFC3209]. The procedures of Call Setup for the revised Notify message are summarized as follows (other procedures are the same as [RFC3974]): (1)The Call-initiator initiates Call setup and processes the Call locally (e.g., verifies the policy, etc.). After that, it adds the Call_ERO to the Notify message, including the sub-objects to identify the Call Path. If Call_RRO is required, it also should add Call_RRO to the Notify message. Then the Call-initiator sends the Notify message to the first Call Manager indicated by the first sub-object of the Call_ERO (Note that there is no Label _Recording for Call_RRO). (2)The transit Call Managers process the Call when they receive the Notify messages. After that, they remove themselves from the Call_ERO. If Call_RRO is presented in the Notify message, it should also process Call_RRO similar to [RFC3209]. Then it sends the Notify message to the next Call Manager identified by the Call_ERO. (3)Step 2 recurs until the Notify message gets to the Call- terminator. And the corresponding Notify message returns to Call- initiator in the inverse direction. If, at any time, the Call_ERO is absent or present but empty (for example, when a transit Call Manager removes itself from the Call_ERO), a Call Manager MUST select a next Call Manager on the Call Path toward the Call-terminator (identified in the Session object of the Notify message). This next Call Manager may be another transit Call Manager or may be the Call-terminator itself. The Call Manager MAY create a new Call_ERO if none exists to define hops to the Call- terminator, or may add hops to the existing Call_ERO between itself and the next hop in the received Call_ERO. Such actions are subject to local policy. 4.1. User-Initiated Calls The extensions in this document can also be applied in user-initiated calls, although the example described in this document is about network-initiated Call. Note that, in this case, the first node within the first network domain may be responsible for specifying the Zhang Expires September 01, 2009 [Page 8] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 Call Path explicitly in the Notify message. The procedures should comply with the description in the Section 7.2 of [RFC 4974]. 5. Security Considerations The security considerations about Call setup in single domain are described in [RFC 4974]. In the case of multi-domain environment, the security about Call is similar to that of Connection which is described in [RFC 5151]. Therefore, please refer to the corresponding Security Consideration sections in [RFC 4974] and [RFC 5151] to take into account the security issues. 6. Manageability Considerations The mechanisms defined in this document call upon the use of policy at Call Managers. Such policy SHOULD be available for configuration by the operator either directly acting on the Call Manager or through a policy server. Important information for the application of policy is carried in the Call establishment messages (Notify messages) in the Session, Session_Attributes, Sender_Template, Link_Capability, and Policy_Data objects. The mechanism used to determine the entire Call Path or next Call Manager in a Call Path is beyond the scope of this document. One solution is to allow configuration of the Call Path from the operator as part of the service request (just as the explicit path of a label switched path (LSP) can be specified by the operator). Operators will expect to be able to inspect Call Managers and determine for which Calls they are initiator, transit, or terminator. Furthermore, they will expect to be able to inspect a Call at any Call Manager that it uses, and determine all information about the Call including its Call Path. 7. IANA Considerations This document introduces two new classes named Call_ERO and Call_RRO. 7.1. Call_ERO Object Class-Num = TBD (0bbbbbbb) C-Type=1 (Call_ERO) The Call_ERO object is only used for Call messages in Notify messages. Subobjects of the Call_ERO object with C-Type 1: Zhang Expires September 01, 2009 [Page 9] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number 7.2. Call_RRO Object Class-Num = TBD (11bbbbbb) C-Type=1 (Call_RRO) The Call_RRO object is only used for Call messages in Notify messages. The subobjects of Call_RRO are defined in Section 3 of this document. 7.3. RSVP Error Codes and Error Values The Call message (Notify message) should be rejected when any Call Manager which receives the Call message including Call_ERO does not recognize the Call_ERO. o Error Codes: - Call Management (value 32) o Error Values: - Call Management/Unknown Call_ERO (value=TBD) 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls ", RFC 4974, August 2007. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Zhang Expires September 01, 2009 [Page 10] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC5151] A. Farrel, A. Ayyangar, JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering-Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", draft-farrel-rtg- common-bnf, work in progress. Zhang Expires September 01, 2009 [Page 11] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 9. Authors' Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973237 Email: danli@huawei.com Jianhua Gao Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: gjhhit@huawei.com Acknowledgment TBD. Intellectual Property The IETF Trust 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 any IETF 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. Zhang Expires September 01, 2009 [Page 12] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Zhang Expires September 01, 2009 [Page 13] Internet-Draft RSVP-TE extensions to GMPLS Calls March 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zhang Expires September 01, 2009 [Page 14]