Internet Engineering Task Force F. Eusebio Internet-Draft Portugal Telecom Intended status: Standards Track December 19, 2007 Expires: June 21, 2007 Ethernet Label Switching (ELS) draft-eusebio-mpls-els-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 IETF Trust (2006). Abstract This document proposes an evolution for MPLS forwarding component, based on a global hierarchical label, in order to reduce the number of labels managed by each router and to provide a stateless fast local repair mechanism. Eusebio Expires June 21, 2007 [Page 1] Internet Draft draft-eusebio-mpls-els-00.txt December 2006 Terminology 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]. 1. Introduction On medium and large IP/MPLS networks, designers have to make a few options in order to prevent hitting the box limits, namely those concerning the maximum number of LSPs. However, the current available alternatives have drawbacks, such as extra complexity, extra cost, and the loss or limited deployment of some features. One of those features is Fast Re-Route (FRR), which builds upon RSVP LSPs. Above a few hundreds of routers a full mesh of RSVP LSPs is far beyond the system limits, which in practice implies either deploying a limited FRR solution (based on LSP stiching or LDPoRSVP) or using LDP (not deploying FRR at all). This document proposes a new label for MPLS, allowing simultaneously an amount of LSPs proportional to the amount of routers (instead of proportional to its square) and a stateless fast local repair mechanism. Both goals are achieved using the following new elements: first, a global hierarchical label in opposition to the local flat 20-bits label; second, multipoint to point (mp2p) LSPs in opposition to point to point (p2p) LSPs widely used in current MPLS deployments. 2. Forwarding plane 2.1 Label structure The proposed label has 2 fields: one that identifies the egress router (destination ID) and another that identifies the path towards it (path ID). +---------+----------------+ | path ID | destination ID | +---------+----------------+ Eusebio Expires June 21, 2007 [Page 2] Internet Draft draft-eusebio-mpls-els-00.txt December 2006 This label has a global scope since the destination ID MUST be unique on the routing domain. The path ID has a scope limited to the destination ID scope, so the same path ID can be used for different destination IDs. Destination ID field has 48 bits and path ID field has 12 bits. This makes the label lookup compatible with a VLAN + MAC lookup on a regular Ethernet switch. Due to the fact that Ethernet tends to be the standard interface used both for router interconnections and for transmission solutions, this label will facilitate the integration of both layers, as explained in section 3. 2.2 Multipoint to point LSPs Since the label has a global meaning, all routers SHALL use the same label for the primary path to a specific egress router, the same label for the seconday path, and so forth. Using the same label for the same egress router results in multipoint to point LSPs (mp2p LSPs). Irrespective of the ingress router the LSP converges to the egress. From a transit router perspective, two packets arriving on different interfaces with the same label (path ID + destination ID) will be forwarded to the same interface. In a scenario with 2 paths from any router to any other router, the maximum number of labels used in the domain would be 2*2*N, N being the number of edge routers. This means that the current LSP limits per router would be enough for any kind of network, even for big networks with a few thousand routers. 2.3 Forwarding The forwarding algorithm is the same as with the 20-bits label: pop-swap-push with an exact lookup on the label forwarding table. However, since the same label is used on every router for the same path, the popped and pushed label are the same. An exception would occur if the next hop link or router fails. As a consequence, the label would be removed from the forwarding table and the lookup would fail. However, assuming that a second label to the same egress router had been distributed (different path ID but the same destination ID) and is active in the forwarding table, the transit router would know about the second path to the same Eusebio Expires June 21, 2007 [Page 3] Internet Draft draft-eusebio-mpls-els-00.txt December 2006 destination. In this case, the label swap MUST push the second label and the packet would be forwarded along the second path towards the egress router, providing a stateless mechanism for fast local repair. 3. Signalling All label distribution protocols being used today (such as LDP, RSVP or BGP) can still be used with a few extensions. These are not the focus of this document and should be defined in other documents. One extension would be needed for the new label. For that new TLVs or objects would have to be defined. Other extensions would be needed for the label distribution procedures, in order to support mp2p LSPs and seting up 2 paths for each PE. Optionally, a common control plane for routers and transmission devices capable of switching VLANs (using PBT, G.709 or other), would allow for a more efficient use of router and transmission resources. 4. IANA considerations IANA will assign two path IDs, one for the primary path and another for the backup path. 5. Security considerations The new label and mp2p LSPs described in this document do not create any new security issues for MPLS. Author address Francisco Eusebio Portugal Telecom Praça Nuno Rodrigues dos Santos, 9 1600-171 Lisboa Portugal email: francisco.m.eusebio@telecom.pt Eusebio Expires June 21, 2007 [Page 4] Internet Draft draft-eusebio-mpls-els-00.txt December 2006 Full 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. 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. Eusebio Expires June 21, 2007 [Page 5]