INTERNET DRAFT Paul Doolan, Ennovate Networks Network Working Group Yasuhiro Katsube, Toshiba Corp Tom K. Johnson, Litchfield Communications Andrew G. Malis, Vivace Networks Rick Wilder, Masergy Tom Worster, Ennovate Networks Expires January 20th 2002 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- 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, et. al. Expires Jan 20th 2002 [Page 1] Internet Draft MPLS Label Stack Encapsulation in IP July 2001 Table of Contents 1. Motivation ................................................... 2 2. MPLS-in-IP protocol specification ............................ 4 3. Usage considerations ......................................... 5 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: Signalled multi-protocol tunnelling By adding FEC types to MPLS signalling, MPLS can be used to Worster, et. al. Expires Jan 20th 2002 [Page 2] Internet Draft MPLS Label Stack Encapsulation in IP July 2001 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 clouds. Worster, et. al. Expires Jan 20th 2002 [Page 3] Internet Draft MPLS Label Stack Encapsulation in IP July 2001 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 [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. Allocation of an IP Protocol Number for MPLS unicast messages is required by MPLS-in-IP encapsulation. For the time being there appears to be no need to allocate an IP Protocol Number for MPLS multicast messages. Worster, et. al. Expires Jan 20th 2002 [Page 4] Internet Draft MPLS Label Stack Encapsulation in IP July 2001 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. 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 suitable. 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 preferable. 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," RFC 3031, Jan 2001. [2] E. Rosen et al, "MPLS Label Stack Encoding," RFC 3032, Jan 2001. [3] L. Andersson et al, "LDP Specification," RFC 3036, Jan 2001. Worster, et. al. Expires Jan 20th 2002 [Page 5] Internet Draft MPLS Label Stack Encapsulation in IP July 2001 [4] Y. Rekhter and E. Rosen, "Carrying Label Information in BGP-4," RFC 3107, May 2001. [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. [7] D. Farinacci et al, "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. 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 Tom K. Johnson Tel: 860-945-1573 Fax: 860-945-1578 Email: tom_johnson@litchfieldcomm.com Litchfield Communications, Inc. 76 Westbury Park Road Watertown, CT, 06795 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 Jan 20th 2002 [Page 6] Internet Draft MPLS Label Stack Encapsulation in IP July 2001 Rick Wilder Masergy, Inc. 2901 Telestar Ct. Falls Church, VA 22042 Tel: 571 217 5408 richard_h_wilder@yahoo.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 Jan 20th 2002 [Page 7]