[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

INTERNET DRAFT                             Paul Doolan, Ennovate Networks
Network Working Group                      Yasuhiro Katsube, Toshiba Corp
                                              Andy Malis, Vivace Networks
                                            Rick Wilder, Broadband Office
                                           Tom Worster, Ennovate Networks

                                                    Expires Aug 22nd 2001

                        MPLS Label Stack Encapsulation in IP


      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-

      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

      The list of Internet-Draft Shadow Directories can be accessed at


      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

      This Internet-Draft explains the motivation for encapsulating MPLS
      messages in IP and provides the protocol specification of the

Worster, et. al.          Expires Aug 22nd 2001               [Page 1]

Internet Draft    MPLS Label Stack Encapsulation in IP       Feb 2000

  Table of Contents

       1. Motivation ................................................... 2

       2. MPLS-in-IP protocol specification ............................ 4

       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|
         +----+        +----+----+        +----+----+        +----+
         +----+        +----+----+        +----+----+        +----+
          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:

         Signalled multi-protocol tunnelling
            By adding FEC types to MPLS signalling, MPLS can be used to

Worster, et. al.            Expires Aug 22nd 2001             [Page 2]

Internet Draft    MPLS Label Stack Encapsulation in IP       Feb 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 multiplexing of
             multiple parallel protocol sessions, e.g. remote access, IP
             Virtual Private Networks with potentially overlapping
             addresses, or multi-hop voice-over-IP headers compression.

  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

Worster, et. al.            Expires Aug 22nd 2001             [Page 3]

Internet Draft    MPLS Label Stack Encapsulation in IP       Feb 2000

2. MPLS-in-IP protocol specification

  MPLS-in-IP messages have the following format:

           |                                     |
           |             IP Header               |
           |                                     |
           |                                     |
           |          MPLS Label Stack           |
           |                                     |
           |                                     |
           |            Message Body             |
           |                                     |

       IP Header
             This field contains an IPv4 or an IPv6 datagram header
             as defined in [5] and [6] respectively. 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

       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

Worster, et. al.            Expires Aug 22nd 2001             [Page 4]

Internet Draft    MPLS Label Stack Encapsulation in IP       Feb 2000

  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

  LDP and BGP directly support sessions between non-adjacent nodes.
  If, however, RSVP is to be used for control of MPLS-in-IP tunnels,
  RSVP packets requiring router alert should be encapsulated using
  IP-in-IP and addressed to the remote tunnel end-point.

  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

  MPLS-in-IP encapsulation is not normally appropriate if an MPLS
  messages needs to be forwarded over a GRE tunnel [7]. In this case
  GRE encapsulation with the Protocol Type set to the corresponding
  ethertype (MPLS Unicast = 0x8847 and MPLS Multicast = 8848) is

4. Security Considerations

  Particular security precautions applicable to MPLS LSRs and LERs
  are applicable also when MPLS-in-IP encapsulation is used.


     [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.

Worster, et. al.            Expires Aug 22nd 2001             [Page 5]

Internet Draft    MPLS Label Stack Encapsulation in IP       Feb 2000

     [7]  S. Hanks et al, "Generic Routing Encapsulation (GRE)," RFC
           1701, October 1994.

Authors' Addresses

   Paul Doolan
   Ennovate Networks, Inc.
   60 Codman Hill Road
   Boxborough, Mass, 01719
   Email: pdoolan@ennovatenetworks.com
   Tel: +1 978 206 0529
   Fax: +1 978 263 1099

   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

   Rick Wilder
   Broadband Office, Inc.
   2900 Telestar Ct.
   Falls Church, VA 22042
   Tel: +1 703 641 6111
   Email: rwilder@bbo.com

   Tom Worster  (contact for comments)
   Ennovate Networks, Inc.
   60 Codman Hill Road
   Boxborough, Mass, 01719
   Email: tom@ennovatenetworks.com
   A.I.M.: "the fsb"
   Tel: +1 978 206 0490
   Fax: +1 978 263 1099

Worster, et. al.            Expires Aug 22nd 2001             [Page 6]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/