Internet DRAFT - draft-eusebio-mpls-els
draft-eusebio-mpls-els
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]
