INTERNET DRAFT T Worster, Ennovate Networks
Network Working Group A Malis, Vivace Networks
Y Katsube, Toshiba Corp
Expires December 26th 2000
MPLS Label Stack Encapsulation in IP
<draft-worster-mpls-in-ip-00.txt>
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
Several useful applications of MPLS tunnels based on LSPs with
second level labels between non adjacent LSRs have been
identified: IP-VPNs and VoIP over MPLS are just two examples. This
tunnelling technique can easily be extended to non-MPLS core
networks.
This Internet-Draft explains the motivation for encapsulating MPLS
messages in IP and provides the protocol specification of the
encapsulation.
Worster Expires Dec 26 2000 [Page 1]
Internet Draft MPLS Label Stack Encapsulation in IP June 2000
Table of Contents
1. Motivation ................................................... 2
2. MPLS-in-IP protocol specification ............................ 3
3. Usage considerations ......................................... 4
4. Security Considerations ...................................... 5
1. Motivation
MPLS provides not only for the label based forwarding of datagrams
by label switching routers (LSRs) but also, through the use of a
second or higher level labels, for the labelled forwarding of
messages between non-adjacent LSRs [1]. This capability may be
used for general purpose tunnelling between non-adjacent LSRs.
Using extended MPLS signalling (e.g. [3] or [4]) and the label
stacking technique, a pair LSRs may establish tunnels on demand
without disturbing the intervening LSRs. Figure 1 illustrates the
"labelled tunnelling" technique.
+----+ +----+
|L2=a| |L2=a|
+----+ +----+----+ +----+----+ +----+
|L1=x|--------|L1=x|L1=y|--------|L1=y|L1=z|--------|L1=z|
+----+ +----+----+ +----+----+ +----+
LSR-1 LSR-2 LSR-3 LSR-4
Figure 1 - Labelled tunnelling over an MPLS network
using a label stack
In this example, an LSP exists between LSR-1 and LSR-4 that is
label switched through LSRs-2 and -3. This LSP has labels x, y and
z on the respective data-links between the LSRs, as shown.
Additionally, LSRs-1 and -4 are directly connected via an LSP with
the label a. (The label having been distributed via an extended
MPLS signalling session, such as LDP or BGP-4, between LSRs-1 and
-4.) This LSP may be used as a "labelled tunnel."
Examples of the utility of this kind of MPLS tunnelling include:
Tunnelling of arbitrary protocols.
By adding FEC types to MPLS signalling, MPLS can be used to
Worster, et. al. Expires Dec 24th 2000 [Page 2]
Internet Draft MPLS Label Stack Encapsulation in IP June 2000
tunnel arbitrary protocols. Alternatively, consistent
configuration of LSRs may be used to associate specific
label spaces with specific protocols. For the tunnelling of
vendor specific protocols the opaque FEC type together with
LDP's vendor specific TLVs may be used to indicate the
encapsulated protocol type.
Tunnelling of multiple protocol sessions.
Extended MPLS signalling allows the efficient establishment
and tear-down of tunnels between a pair of LSRs. This
facility has value in the support of certain protocol
stacking techniques that require the separation of multiple
parallel protocol sessions, such as in remote access or
virtual private IP networks using potentially overlapping
addresses.
The MPLS-in-IP encapsulation specified in Section 2 allows the use
of labelled tunnelling in those situations in which the
intervening network nodes are not MPLS LSRs. Figure 2 contrasts
this technique with the label stacking technique shown in Figure
1. The inherent protocol layering hides the differences between
labelled tunnelling over MPLS (Figure 1) and labelled tunnelling
over IP (Figure 2) from the tunnelled protocol layer and layers
above, and from the extended MPLS signalling session between LSR-1
and LSR-2.
+----+ +----+
|L1=a| |L1=a|
+----+ +----+
|MiIP| |MiIP|
+----+ +---------+ +---------+ +----+
| IP |--------| IP |--------| IP |--------| IP |
+----+ +---------+ +---------+ +----+
LSR-1 Router Router LSR-2
Figure 2 - Labelled tunnelling over an IP network using
MPLS-in-IP (MiIP) encapsulation
Thus an MPLS-in-IP encapsulation extends the applicability of
extended MPLS signalling and labelled tunnelling to use over non-MPLS
clouds.
2. MPLS-in-IP protocol specification
MPLS-in-IP messages have the following format:
Worster, et. al. Expires Dec 24th 2000 [Page 3]
Internet Draft MPLS Label Stack Encapsulation in IP June 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MPLS Label Stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Header
This field contains an IPv4 or an IPv6 datagram header
as defined in [5] and respectively [6]. The source and
destination addresses are set to addresses of the
encapsulating and decapsulating LSRs respectively.
MPLS Label Stack
This field contains an MPLS Label Stack as defined in
[2].
Message Body
This field contains one MPLS message body.
The Protocol Number field in an IPv4 header and the Next Header
field in an IPv6 are set as follows:
X indicates an MPLS unicast message,
Y indicates an MPLS multicast message.
3. Usage considerations
MPLS-in-IP is useful when an MPLS tunnel is useful but where an
MPLS network between the tunnel end-points is not available. It
should be noted, however, that certain capabilities often connoted
with MPLS are not available with MPLS-in-IP. Firstly, RSVP and CR-
LDP cannot provide resource allocation (e.g. bandwidth allocation)
for the tunnels since the signalling does not interact with the
network between the tunnel endpoints. Other techniques applicable
at the IP level, such as Diff-Serv or RSVP/Int-Serv, may be used
in conjunction with MPLS-in-IP. Secondly, in MPLS-in-IP, RSVP and
CR-LDP signalling cannot provide control of a source route for the
tunnels.
Worster, et. al. Expires Dec 24th 2000 [Page 4]
Internet Draft MPLS Label Stack Encapsulation in IP June 2000
If RSVP is to be used for control of MPLS-in-IP tunnels, the UDP
encapsulation is applicable.
The source and destination addresses in the IP Header of MPLS-in-
IP messages may be any of the respective encapsulating and
decapsulating LSRs' addresses. Usually the LSR Ids will be
suitable.
4. Security Considerations
Particular security precautions applicable to MPLS LSRs and LERs
are applicable also when MPLS-in-IP encapsulation is used.
References
[1] E. Rosen et al, "Multiprotocol Label Switching
Architecture," Internet-Draft draft-ietf-mpls-arch-06,
work in progress, Aug 1999.
[2] E. Rosen et al, "MPLS Label Stack Encoding," Internet-
Draft draft-ietf-mpls-label-encaps-07, work in progress,
Sep 1999.
[3] L. Andersson et al, "LDP Specification," Internet-Draft
draft-ietf-mpls-ldp-08.txt, work in progress, Jun 2000.
[4] E. Rosen et al, "Carrying Label Information in BGP-4,"
Internet Draft draft-ietf-mpls-bgp4-mpls-04, Jan 2000.
[5] J. Postel, "Internet Protocol," STD 5, RFC 791, Sep 1981.
[6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," RFC 2460, Dec 1998.
Authors' Addresses
Tom Wortster (contact for comments)
Ennovate Networks, Inc.
60 Codman Hill Road
Boxborough, Mass, 01719
Email: tom@ennovatenetworks.com
Tel: +1 978 206 0490
Fax: +1 978 263 1099
Worster, et. al. Expires Dec 24th 2000 [Page 5]
Internet Draft MPLS Label Stack Encapsulation in IP June 2000
Yasuhiro Katsube
Toshiba Corporation
1, Toshiba-cho,
Fuchu, Tokyo 183-8511
Email: yasuhiro.katsube@toshiba.co.jp
Tel: +81 42 333 2884
Fax: +81 42 340 8059
Andrew G. Malis
Vivace Networks
2730 Orchard Parkway
San Jose, CA 95134
Email: Andy.Malis@vivacenetworks.com
Tel: +1 408 383 7223
Fax: +1 408 904 4748
Worster, et. al. Expires Dec 24th 2000 [Page 6]