Network Working Group Internet Draft Kenji Kumaki Category: Informational KDDI Corporation Expires: August 2006 February 2006 Requirements for delivering MPLS Services Over L3VPN draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes Service Provider requirements for providing end-to-end MPLS TE LSPs over L3VPN. The main objective is to present a set of requirements which result in general guidelines for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is out of scope in this document. K.Kumaki Expires - August 2006 [Page 1] Requirements for delivering MPLS Services Over L3VPN February 2006 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. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Problem Statement..............................................4 4. Reference model................................................4 5. Detailed Requirements..........................................5 5.1 Selective MPLS TE LSPs.....................................6 5.2 Graceful restart support for end-to-end MPLS TE LSPs.......6 5.3 Rerouting support for end-to-end MPLS TE LSPs..............6 5.4 FRR support for end-to-end MPLS TE LSPs....................6 5.5 Policy control support for end-to-end MPLS TE LSPs.........6 5.6 PCE features support for end-to-end MPLS TE LSPs...........7 5.7 Diversely routed end-to-end MPLS TE LSPs support...........7 5.8 Optimal path support for end-to-end MPLS TE LSPs...........7 5.9 Reoptimization support for end-to-end MPLS TE LSPs.........7 5.10 DS-TE support for end-to-end MPLS TE LSPs.................7 5.11 Complexity and Risks......................................8 5.12 Backward Compatibility....................................8 5.13 Scalability consideration.................................8 5.14 Performance consideration.................................8 5.15 Management consideration..................................9 6. Security Considerations........................................9 7. Normative References...........................................9 8. Informative References........................................10 9. Acknowledgments...............................................10 10. Author's Addresses...........................................11 11. Intellectual Property Statement..............................11 1. Introduction L3VPN service providers are presented with two conflicting requirements. The first requirement states that service provider network must protect itself from any misconfiguration or misbehavior on the part of any particular customer. When one customer behaves badly, the service provider must continue to provide service to its remaining customers. As a consequence, many service providers maintain a security posture in which all customer interfaces are mediated by a Virtual Routing and Forwarding (VRF) instance. Customers cannot forward packets K.Kumaki Expires - August 2006 [Page 2] Requirements for delivering MPLS Services Over L3VPN February 2006 through the service provider's general forwarding instance, nor can they join the service provider's intra-domain routing or MPLS signaling domain. The second requirement is for service providers to offer robust MPLS services to their customers. In order to understand this requirement, assume that the customer maintains sites of connectivity on either side of a service provider network. In order to fulfill the requirement, the customer must be able to establish and maintain an MPLS LSP from any router in one site to any router in the other site. For the purposes of this document, we will call this customer LSP an "end-to-end LSP". The customer deploys end-to-end LSPs in order to construct diverse services that, in turn, are offered to the customer's users. These diverse services might include L1VPN, L2VPN, L3VPN or other MPLS- enabled services that have yet to be defined. The end-to-end LSP must be robust. This is to say that it must be enabled with many of the features that one would expect from a traffic engineered intra-domain LSP. These features include traffic engineering by means of bandwidth reservation, administrative groups and priority. They also include differentiated services on the forwarding plane and fast reroute on the control plane. Furthermore, the solution must offer all of the benefits of a Layer 3 VPN. Specifically, the interfaces that connect the customer's edge router to the service provider's edge router need not be numbered from globally unique address space. They can be numbered from address space that is unique only to the VPN. At first glance, the two requirements discussed above appear to be in conflict with one another. However, they can be harmonized using mechanism such as LSP hierarchies and/or routing and signaling policy. This document defines detailed requirements for providing an end-to- end MPLS TE LSP. Although this document presents a reference model, this reference model may not be considered as part of the solution. The reference model is intended only to provide a conceptual framework for subsequent solution documents. 2. Terminology LSP: Label Switched Path TE LSP: Traffic Engineering Label Switched Path MPLS TE LSP: Multi Protocol Label Switching TE LSP K.Kumaki Expires - August 2006 [Page 3] Requirements for delivering MPLS Services Over L3VPN February 2006 VPN: Virtual Private Network CE: Customer Edge Equipment PE: Provider Edge Equipment that has direct connections to CEs from the Layer3 point of view. P: Provider Equipment that has backbone trunk connections only. VRF: Virtual Private Network (VPN) Routing and Forwarding Instance PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. Head-end LSR: ingress LSR Tail-end LSR: egress LSR LSR: Label Switched Router 3. Problem Statement When service providers provide an end-to-end MPLS TE LSP, they expect a MPLS TE LSP from a local CE to a remote CE is established. But if service providers provide an end-to-end MPLS TE LSP using L3VPN, especially BGP/MPLS IP-VPNs [RFC2547bis], they can't provide it over vrf instance. In current BGP/MPLS IP-VPN architecture, it does not define a vrf instance which receives a RSVP signaling packet and processes this packet. Furthermore, an end-to-end MPLS TE LSP established over BGP/MPLS IP- VPNs is not scalable due to the number of RSVP control message and retained state because a lot of MPLS TE LSPs exist in an actual BGP/MPLS IP-VPN. This problem happens in carrier's carrier environments [RFC2547bis] as well as in basic BGP/MPLS IP-VPN environments. Scalable end-to-end MPLS TE LSPs are needed through BGP/MPLS IP-VPNs. 4. Reference model This section describes an end-to-end MPLS TE LSP and a MPLS TE LSP in L3VPN, especially BGP/MPLS IP-VPNs. K.Kumaki Expires - August 2006 [Page 4] Requirements for delivering MPLS Services Over L3VPN February 2006 In a BGP/MPLS IP-VPN, an end-to-end MPLS TE LSP and a MPLS TE LSP are shown in figure 1. CE0 and/or CE1 send a path message to CE2 and/or CE3 respectively over vrf instance. The rsvp control messages (i.e. a RSVP PATH message and a RSVP RESV message and so on) are forwarded by labeled packet through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, it establishes an end-to-end MPLS TE LSP through the BGP/MPLS IP-VPN. A MPLS TE LSP is established between PE1 and PE2. This LSP is used by vrf instance to forward customer packets within the BGP/MPLS IP-VPN. Generally speaking, end-to-end MPLS TE LSPs are used by customers and MPLS TE LSPs are used by service providers. e2e MPLS TE LSP <-----------------------------------------------------------> or e2e MPLS TE LSP <----------------------------------------------> MPLS TE LSP <---------------------------> ............. ............. . --- --- . --- --- --- --- . --- --- . .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|. . --- --- . --- --- --- --- . --- --- . ............. ............. ^ ^ | | vrf instance vrf instance <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> network network or or another another service provider service provider network network Figure 1 Reference model 5. Detailed Requirements This section describes detailed requirements for end-to-end MPLS TE K.Kumaki Expires - August 2006 [Page 5] Requirements for delivering MPLS Services Over L3VPN February 2006 LSPs in L3VPN environments, especially BGP/MPLS IP-VPN environments. 5.1 Selective MPLS TE LSPs The solution MAY provide the ability to decide which MPLS TE LSP a PE uses for an end-to-end MPLS TE LSP. When a PE receives a path message from a CE, it may be able to decide which MPLS TE LSP it uses. In this case, various kinds of MPLS TE LSPs exist in service provider network. For example, depending on an application (e.g. voice, television, video and so on), the PE MAY choose an appropriate MPLS TE LSP. 5.2 Graceful restart support for end-to-end MPLS TE LSPs The solution SHOULD provide graceful restart for an end-to-end MPLS TE LSP over vrf instance. Graceful restart mechanisms related to this architecture are described in [RFC3623][GR-BGP/MPLS][RFC3473]. 5.3 Rerouting support for end-to-end MPLS TE LSPs The solution MUST provide rerouting of an end-to-end MPLS TE LSP in case of link/node/SRLG failures or preemption. Such rerouting may be controlled by a CE or by a PE. 5.4 FRR support for end-to-end MPLS TE LSPs The solution MUST support FRR [RFC4090] features for an end-to-end MPLS TE LSP over vrf instance. In BGP/MPLS IP-VPN environments, an end-to-end MPLS TE LSP from CE traverses over multiple PEs and Ps. To avoid link/node/SRLG failures needs to support a fast local protection or a fast path protection. 5.5 Policy control support for end-to-end MPLS TE LSPs The solution MAY support policy control for an end-to-end MPLS TE LSP at a PE. A PE receives RSVP control messages from a CE. The PE has the possibility that receives unexpected packets from the CE site. The PE may control RSVP control messages per vrf instance. Especially, if a CE is not managed by service providers, the PE has the high possibility that receives unexpected packets from the CE site. In this case, the PE should control RSVP control messages per vrf instance. Furthermore, PEs cooperated with Operating Support System (OSS) interpret a bandwidth customers require and may assign a bandwidth for a customer. K.Kumaki Expires - August 2006 [Page 6] Requirements for delivering MPLS Services Over L3VPN February 2006 5.6 PCE features support for end-to-end MPLS TE LSPs The solution MAY support PCE features for an end-to-end MPLS TE LSP over vrf instance. When an end-to-end MPLS TE LSP is provided, CEs, PEs and Ps may support PCE [PCE-ARCH] [PCEP] features. In this case, CE routers or PE routers have PCC functions and PE routers and/or P routers have PCE functions. 5.7 Diversely routed end-to-end MPLS TE LSPs support The solution SHOULD set up a diversely routed end-to-end MPLS TE LSP over vrf instance. When a CE has multiple uplinks which connect to different PEs, it is desirable that multiple end-to-end MPLS TE LSPs over vrf instance are established. In this case, for example, the following points will be beneficial to customers. - If multiple end-to-end MPLS TE LSPs from a CE to a remote CE exist and some of them do not satisfy required set of constraints, packet forwarding from the CE to the remote CE does not impact. - path protection (e.g. 1:1, 1:N) 5.8 Optimal path support for end-to-end MPLS TE LSPs The solution MUST support an optimal path of an end-to-end MPLS TE LSP over vrf instance. Depending on an application (e.g. voice, television and video), an optimal path is needed for an end-to-end MPLS TE LSP over vrf instance. An optimal path may be a shortest path based on TE metric or IGP metric. 5.9 Reoptimization support for end-to-end MPLS TE LSPs The solution MUST support reoptimization of an end-to-end MPLS TE LSP over vrf instance. These LSPs must be reoptimized by make-before-break. In this case, it is desirable for a head-end LSR to be configured with regard to timer-based or event-driven reoptimization. Furthermore, customers should be able to reoptimize an end-to-end MPLS TE LSP manually. To provide delay- or jitter-sensitive traffic (i.e. voice traffic), an end-to-end MPLS TE LSP should be optimally established. 5.10 DS-TE support for end-to-end MPLS TE LSPs The solution SHOULD support DS-TE [RFC4124] features for an end-to- end MPLS TE LSP over vrf instance. K.Kumaki Expires - August 2006 [Page 7] Requirements for delivering MPLS Services Over L3VPN February 2006 Applications, which have different traffic characteristics, are used in BGP/MPLS IP-VPN environments. Service providers try to achieve fine-grained optimization of transmission resources, efficiency and further enhanced network performance. It may be desirable to perform TE at a per-class level. By mapping the traffic from a given diff-serv class of service on a separate LSP, it allows this traffic to utilize resources available to the given class on both shortest paths and non-shortest paths, and follow paths that meet TE constraints which are specific to the given class. Requirements for DS-TE are described in [RFC3564]. 5.11 Complexity and Risks The solution SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks. 5.12 Backward Compatibility The deployment of end-to-end MPLS TE LSPs SHOULD NOT impact existing MPLS TE mechanisms, but allow for a smooth migration or co-existence. 5.13 Scalability consideration The solution MUST have a minimum impact on network scalability from an end-to-end MPLS TE LSP over vrf instance. Scalability of end-to-end MPLS TE LSPs MUST addresses the following consideration. - RSVP-TE (e.g. number of RSVP control messages, retained state, message size and so on) - BGP (e.g. number of routes, flaps, overload events and so on) If the number of required end-to-end MPLS TE LSPs increases, there would be scalability issues. In this case, PEs may support a hierarchical LSP [RFC4206]. 5.14 Performance consideration The solution SHOULD be evaluated with regard to the following criteria. - Degree of path optimality of the end-to-end MPLS TE LSP - TE LSP setup time - Failure and restoration time - Impact and scalability of the control plane due to added overheads and so on - Impact and scalability of the data/forwarding plane due to added K.Kumaki Expires - August 2006 [Page 8] Requirements for delivering MPLS Services Over L3VPN February 2006 overheads and so on 5.15 Management consideration Manageability of end-to-end MPLS TE LSPs MUST addresses the following consideration for section 5. - need for a MIB module for control plane and monitoring - need for diagnostic tools MIB module for end-to-end MPLS TE LSPs should be got per vrf instance. If a CE is managed by service providers, MIB information for end-to- end TE LSPs from the CE should be got per customer. Today, diagnostic tools can detect failures of control plane and data plane for general MPLS TE LSPs [LSP-PING]. The diagnostic tools must detect failures of control and data plane for end-to-end MPLS TE LSPs over vrf instance. In BGP/MPLS IP-VPN environments, from a CE point of view, IP TTL decreases at a local PE and a remote PE. But from a PE point of view, both IP TTL and MPLS TTL decreases between PEs. 6. Security Considerations Security issues for end-to-end TE LSPs relate to both control plane and data plane. In terms of control plane, a PE receives IPv4 or IPv6 RSVP control packets from a CE. If the CE is an untrusted router for service providers, the PE MUST be able to control IPv4 or IPv6 RSVP control packets. If the CE is a trusted router for service providers, the PE MAY be able to control IPv4 or IPv6 control packets. In terms of data plane, a PE receives labeled IPv4 or IPv6 data packets from a CE. If the CE is an untrusted router for service providers, the PE MUST be able to control labeled IPv4 or IPv6 data packets. If the CE is a trusted router for service providers, the PE MAY be able to control labeled IPv4 or IPv6 data packets. In BGP/MPLS IP-VPN environments, from a CE point of view, IP TTL should decrease at a local PE and a remote PE to hide service provider network topology. 7. Normative References [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. K.Kumaki Expires - August 2006 [Page 9] Requirements for delivering MPLS Services Over L3VPN February 2006 [RFC2547bis]Rosen, E., and Rekhter, Y., "BGP/MPLS IP VPNs", Work in Progress, October 2004. [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC3623] Moy, J., et al., "Graceful OSPF Restart", RFC3623, November 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. [RFC3564] Le Faucheur, F., and Lai, W., "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering ", RFC 3564, July 2003. [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. 8. Informative References [GR-BGP/MPLS]Rekhter, Y., and Aggarwal, R., " Graceful Restart Mechanism for BGP with MPLS", Work in Progress, August 2005. [PCE-ARCH] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation Element (PCE) Architecture", Work in Progress, December 2005. [PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", Work in Progress, December 2005. [LSP-PING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", Work in Progress, January 2006. 9. Acknowledgments The author would like to express the thanks to Ron Bonica, Koh Yamashita, Miya Kohno, Tomohiro Otani for helpful and useful comments and feedbacks. K.Kumaki Expires - August 2006 [Page 10] Requirements for delivering MPLS Services Over L3VPN February 2006 10. Author's Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Email: ke-kumaki@kddi.com 11. Intellectual Property Statement 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. K.Kumaki Expires - August 2006 [Page 11] Requirements for delivering MPLS Services Over L3VPN February 2006 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. K.Kumaki Expires - August 2006 [Page 12]