Network Working Group Z. Li Internet-Draft X. Zeng Intended status: Standards Track Huawei Technologies Expires: January 09, 2014 July 08, 2013 Proxy MPLS Traffic Engineering Label Switched Path(LSP) draft-li-mpls-proxy-te-lsp-00 Abstract This document describes a method to setup MPLS TE proxy egress LSP which helps setup end-to-end LSP through stitching MPLS TE proxy egress LSP with BGP LSP in the Seamless MPLS network. The method is achieved by new Proxy Destination Object carried in RSVP-TE messages. Requirements Language 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]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 09, 2014. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Li & Zeng Expires January 09, 2014 [Page 1] Internet-Draft Proxy TE LSP July 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Proxy Destination Object . . . . . . . . . . . . . . . . . . 4 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Seamless MPLS[I-D.ietf-mpls-seamless-mpls] provides an end to end service independent transport architecture. It removes the need for service specific configurations in network transport nodes. Seamless MPLS uses existing protocols like LDP, IS-IS to build intra-area segments and uses MP-BGP as the inter-area routing and label distribution protocol. One common procedure of setting up the end-to-end transport LSP is as follows: 1. Setup the access segment LSP from Access Node (AN) to Aggregation Node (AGN) using LDP with longest-match as defined in [RFC5283]. It requires only static routes and it is not necessary to know the actual destination (FEC of the LDP LSP); 2. The Aggregation Node (AGN) stitches the egress LDP LSP with the BGP ingress LSP according to the key of FEC; 3. The remote Aggregation Node (AGN) stitches the egress BGP LSP with an ingress LSP according to the key of FEC. LSPs set up with MPLS TE (RSVP-TE) provide a higher reliability and better QoS as compared to LSPs set up with LDP. So MPLS TE is always adopted to deploy in the mobile backhaul network. But when the mobile backhaul network integrates with the core/aggregation network based on Seamless MPLS, it is difficult to setup end-to-end MPLS TE Li & Zeng Expires January 09, 2014 [Page 2] Internet-Draft Proxy TE LSP July 2013 LSP spanning multiple domains. The possible way to setup the end-to- end LSP is that the proxy egress RSVP-TE LSP should be able to setup in the mobile backhaul network to stitch with BGP LSP at the Aggregation Node. This document extends RSVP-TE extension and introduces a new Proxy Destination Object. Through the RSVP-TE extension the proxy egress LSP can setup for RSVP-TE. It makes possible to setup the end-to-end LSP when deploy MPLS TE in the Seamless MPLS scenario to integrate the mobile backhaul network with the core/aggregation network. 2. Terminology Proxy Egress LSP: It is defined in Sec. 4.1.4 of [RFC3031]. It is the LSP which is setup by the proxy egress LSR instead of the actual destination LSR. 3. Solutions When setup a proxy egress RSVP-TE LSP in the Seamless MPLS scenario as shown in the Figure 1, there are two destination addresses to be carried by the RSVP-TE message: the actual destination address is the destination address of the end-to-end LSP by stitching the proxy egress LSP and the BGP LSP, the proxy destination address is the address of Aggregation Node which stitches the proxy egress RSVP-TE LSP and BGP LSP. When setting up the proxy egress RSVP-TE LSP on the Access Node, it is necessary to specify the actual destination address and the proxy destination address. The access node needs to calculate the path based on the proxy destination address for the proxy egress RSVP-TE LSP. The Path message will be sent from the ingress node to the proxy destination node which is identified by the proxy destination address in the message. Then the proxy destination node sends back the Resv message to allocate label and reserve resource. The actual destination address is used to stitch with BGP LSP which has the same address as the actual destination address of the proxy egress RSVP-TE LSP. | IGP X | | IGPY | |(Access/Aggregation)| (Core) |Access/Aggregation)| |--------------------|--------------|-------------------| | | | | +-----+ +-----+ ...|AGN |.......|AGN |.... +----+ ........ +-----+ +-----+ ....... +----+ | AN |... ...| AN | +----+ ..... ..... +----+ ..... +-----+ +-----+ ..... Li & Zeng Expires January 09, 2014 [Page 3] Internet-Draft Proxy TE LSP July 2013 ..|AGN |.......|AGN |.. +-----+ +-----+ | | Hierarchical | | | | BGP LSP | | | +--------------------+ | | MPLS TE LSP | | MPLS TE LSP | +-----------------+ +---------------+ | |--------------------| | | | MPLS LDP | | Figure 4 Seamless MPLS Scenario with MPLS TE In order to support setup of the proxy egress RSVP-TE LSP, the new Proxy Destination Object is introduced to carry the proxy destination address besides that the actual destination address is carried in the Session Object. Both the Session Object and the Proxy Destination Object are carried in the RSVP-TE Path message and Resv message to set up the proxy egress LSP. 4. Proxy Destination Object 4.1. Format The Proxy Destination Object is an optional object which may be carried in Path or Resv Messages. The Proxy Destination Class-Number is TBD (of form 0bbbbbbb). RSVP-TE routers that do not support the object SHOULD reject the entire message and return an "Unknown Object Class" error. The format of the Proxy Destination Object is as follows: 1. IPv4 Proxy Destination Object 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 (1) | C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Proxy Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Proxy Destination Address: 32 bits. IPv4 address of the proxy destination address of the proxy egress RSVP-TE LSP. 2. IPv6 Proxy Destination Object Li & Zeng Expires January 09, 2014 [Page 4] Internet-Draft Proxy TE LSP July 2013 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 (2) | C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Proxy Destination Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Proxy Destination Address: 16 bytes. IPv6 address of the proxy destination address of the proxy egress RSVP-TE LSP. If a message contains multiple Proxy Destination Objects, only the first object is meaningful. Subsequent Proxy Destination Objects SHOULD be ignored and SHOULD NOT be propagated. 4.2. Procedures When the ingress node sets up the proxy egress LSP, the Proxy Destination Object MUST be inserted in the Path message to indicate the address of the proxy destination node that would stitch the proxy egress LSP with other LSPs. When receive the RESV messages, the ingress node SHOULD check if the Proxy Destination is included. If the Path message include the Proxy Destination object and the corresponding RESV message does not include this object, the ingress node MUST treat the Resv message as wrong messages and MUST NOT set up LSP. On the transit node, when receiving the messages with Proxy Destination object, it MUST include the Proxy Destination object in the outgoing Path or Resv message without change of the object. When it is necessary for the transit node to calculate the path, the proxy destination address identified by the Object MUST be used instead of the actual destination address identified by the Session Object. If the transit node receives the Path message including the Proxy Destination object but receives the corresponding Resv message which does not include this object, it MUST treat the Resv message as wrong message can MUST NOT set up LSP. On the egress node, when receiving Path messages with Proxy Destination object, it MUST include this object in the corresponding Resv message. 5. IANA Considerations TBD. Li & Zeng Expires January 09, 2014 [Page 5] Internet-Draft Proxy TE LSP July 2013 6. Security Considerations This document does not introduce any additional security issues above those identified in [RFC3209]. 7. Acknowledgements The authors would like to thank Loa Andersson for his valuable comments and suggestions on this draft. 8. Normative References [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft- ietf-mpls-seamless-mpls-03 (work in progress), May 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [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. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li & Zeng Expires January 09, 2014 [Page 6] Internet-Draft Proxy TE LSP July 2013 Xinzong Zeng Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zengxinzong@huawei.com Li & Zeng Expires January 09, 2014 [Page 7]