Internet DRAFT - draft-bitar-mpls-isis-explicit-null-label
draft-bitar-mpls-isis-explicit-null-label
MPLS Working Group Nabil Bitar
Internet Draft Verizon
Intended status: Standards Track
Expires: April 24, 2012 Himanshu Shah
Ciena
George Swallow
Cisco
October 24, 2011
ISIS MPLS Explicit NULL Label
draft-bitar-mpls-isis-explicit-null-label-00.txt
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), 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 April 24,2012.
Copyright Notice
Copyright (c) 2011 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
Bitar, et al. Expires April 24, 2012 [Page 1]
Internet-Draft ISIS MPLS Explicit NULL Label October 2011
(http://trustee.ietf.org/license-info) in effect on the date
of publication of this document. Please review these
documents carefully, as they describe your rights and
restrictions with respect to this document.
Abstract
There is need to support IP interfaces on the top of GMPLS
packet Label Switched Paths (LSPs), and enable IP routing
(e.g., OSPF-TE, ISIS-TE) and MPLS protocols on these
interfaces. Traffic on an IP/MPLS interface can be user
traffic or control traffic. In addition, it can be MPLS, IP
or ISIS. Multiplexing IP and MPLS packets over the same LSP
is supported in the current MPLS architecture. However,
multiplexing IP, MPLS, and ISIS packets over the same LSP is
not currently supported. This draft proposes the definition
of an explicit ISIS NULL label to enable this type of
multiplexing to take place.
Table of Contents
1. Introduction..............................................2
2. Operational Procedures....................................3
3. ISIS Packet Encapsulation format..........................5
4. IANA Consideration........................................6
5. Security Considerations...................................6
6. References................................................6
6.1. Normative References.................................6
6.2. Informative References...............................6
1. Introduction
RFC 4206 [RFC 4206] defines the concept of a forwarding
adjacency (FA) built on a Traffic Engineered (TE) LSP. An FA
can be unidirectional and signaled via RSVP-TE, or
bidirectional and signaled via RSVP-TE with GMPLS
extensions. It is signaled over the same network on which
it is routed. An FA is included in the network IGP link
state database as a TE link but used only for forwarding.
That is, it is never used to establish a routing adjacency.
Routing adjacencies are necessary in a link-state IGP
network for topology discovery and link-state information
dissemination. FAs capitalize on the existence of routing
adjacencies, and routers make use of the topology
information exchanged over these adjacencies to establish
the FAs.
Bitar, et al. Expires April 24, 2012 [Page 2]
Internet-Draft ISIS MPLS Explicit NULL Label October 2011
In MPLS-TP, client network islands that belong to the same
IGP are interconnected over an MPLS-TP [RFC 5921] server
network in an overlay model. A client network island is
connected to the MPLS-TP network via a border client router.
Two client border-routers need to form a routing adjacency
over a GMPLS LSP signaled through the MPLS-TP network via
GMPLS UNI signaling. The GMPLS UNI is the interface between
the client border node and the connected MPLS-TP network
edge.
This document introduces the explicit ISIS NULL label that
enables the establishment of an ISIS(-TE) routing
adjacency over a GMPLS LSP, and to treat that routing
adjacency as any IP adjacency, enabling MPLS signaling, IP and
MPLS multicast signaling/routing, and MPLS and IP forwarding
over that adjacency.
2. Operational Procedures
<-------- ISIS, RSVP-TE, LDP, PIM, LDP, BFD ------>
<---------- Tunnel LSP: Routing Adjacency -------->
<---Transport LSP--->
GMPLS UNI GMPLS UNI
+-+--+ +----+ +----+ +----+
| R1 |+-------+| PE1|+-----------------+|PE2 |+-----+| R2 |
+----+ +----+ +----+ +----+
Figure 1: Reference Model for GMPLS LSP Tunnel as an IP
interface
Figure 1 depicts a reference model for the GMPLS UNI and
GMPLS LSP routing adjacency, referred to as tunnel LSP. R1
connects to the MPLS transport network via a GMPLS UNI
interface between R1 and PE1. R2 connects to the MPLS
transport network via a GMPLS UNI interface between R2 and
PE2. A GMPLS tunnel LSP is signaled over the GMPLS
Bitar, et al. Expires April 24, 2012 [Page 3]
Internet-Draft ISIS MPLS Explicit NULL Label October 2011
UNI and across the MPLS transport network. The LSP endpoint at
R1 is presented as an IP interface to R1. The LSP endpoint at
R2 is presented as an IP interface to R2. ISIS(-TE) is
enabled on these IP interfaces. In addition, other IP-based
protocols such as RSVP-TE, LDP, PIM-SM(SSM), etc., can be
enabled on these interfaces. It should be noted that if OSPF
is enabled in addition or instead of ISIS over these
interfaces, OSPF packets can be carried over the GMPLS LSP
tunnel using the existing MPLS encapsulation architecture
[RFC 3032] for transporting IP packets.
When the tunnel LSP is active at R1 and R2, ISIS adjacency
formation starts and ISIS adjacency is established. Subsequent
to that ISIS Link state packets are flooded over that LSP as
on any other ISIS link. Other LSPs can be established over
this ISIS link (the LSP tunnel) via RSVP-TE, GMPLS, LDP, etc.
When R1 sends an ISIS packet to R2, it first imposes the
explicit ISIS NULL label whose value TBD, with the S-bit to 1,
the TC set to a configured value, and TTL set to 1, and then
encapsulates the MPLS packet with the LSP tunnel header.
When R1 sends R2 an IPv4 control protocol (e.g., RSVP-TE,
LDP, PIM), or a user IPv4 packet, it encapsulates the IPv4
packet with the LSP tunnel header.
When R1 sends R2 an IPv6 control protocol (e.g., RSVP-TE,
LDP, PIM), or a user IPv6 packet, it first imposes on the
packet the IPv6 Explicit NULL label (label value = 2) with
the S bit set to 1, followed by a label header corresponding
to the GMPLS LSP tunnel.
When R1 sends an MPLS packet to R2, it encapsulates the MPLS
packet with the LSP tunnel header. In this case, R1 may be a
transit node for the LSP whose MPLS packet is being switched
across the tunnel GMPLS LSP, or the head-end of that LSP.
Upon receiving a packet over the GMPLS LSP tunnel configured
as a routing adjacency, R1 performs the following
processing:
1. It pops the GMPLS LSP label, preserving the context of
that label as an IP interface
Bitar, et al. Expires April 24, 2012 [Page 4]
Internet-Draft ISIS MPLS Explicit NULL Label October 2011
2. If the encapsulated packet is an MPLS packet, as
indicated by the outer label (tunnel label) tag S-bit
set to 0, R1 performs a label lookup on the top label,
after popping the tunnel label. The following cases
exist:
a. The label matches the ISIS Explicit NULL label
value: the encapsulated packet is an ISIS packet.
The ISIS packet is sent to the control plane.
b. The label matches the IPv6 Explicit NULL label
value: the encapsulated packet is an IPv6 packet,
the IPv6 Explicit Null label is popped, and the
IPv6 packet is routed appropriately.
c. Otherwise, the label is switched, or popped
depending on the label context.
3. If the encapsulated packet is not an MPLS packet,
(i.e., the tunnel label had the S bit set to 1), it is
assumed that the encapsulated packet is an IPv4 packet.
3. ISIS Packet Encapsulation format
Figure 2 depicts the protocol stack for an ISIS packet
encapsulated over the GMPLS LSP tunnel.
+-------------------------------+
Tunnel label header | tunnel-label | TC| S=0| TTL |
|-------------------------------|
ISIS Explicit NULL label |ISIS NULL label| TC| S=1| TTL=1|
|-------------------------------|
| |
| |
| ISIS Packet |
| |
| |
| |
| |
+-------------------------------+
Figure 2: Encapsulation of an ISIS packet in a tunnel LSP
treated as a routing adjacency
Bitar, et al. Expires April 24, 2012 [Page 5]
Internet-Draft ISIS MPLS Explicit NULL Label October 2011
4. IANA Consideration
This document requires the designation of a label value in
the reserved MPLS Label space for the ISIS Explicit NULL
label.
5. Security Considerations
No new security issues are introduced in this document
beyond what is addressed for MPLS, GMPLS and all the IP
protocols.
6. References
6.1. Normative References
[RFC 3032] Rosen, E., et. al, "MPLS Label Stack Encoding",
RFC 3032, January, 2011.
[RFC 5921] Bocci, M., et. al, "A Framework for MPLS in
Transport Networks", RFC 5921, July 2010.
6.2. Informative References
[RFC 4206] Kompella, K., and Rekhter, Y., "Label Switched
Paths (LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
Authors' Addresses
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Himanshu Shah
Ciena Corp
Email: hshah@ciena.com
Bitar, et al. Expires April 24, 2012 [Page 6]
Internet-Draft ISIS MPLS Explicit NULL Label October 2011
George Swallow
Cisco
Email: swallow@cisco.com
Bitar, et al. Expires April 24, 2012 [Page 7]
