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

Versions: (draft-rosen-mpls-in-ip-or-gre) 00 01 02 03 04 05 06 07 08 RFC 4023

Network Working Group                                        Tom Worster
Internet Draft
Expiration Date: March 2004
                                                           Yakov Rekhter
                                                  Juniper Networks, Inc.

                                                   Eric C. Rosen, editor
                                                     Cisco Systems, Inc.

                                                          September 2003


    Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)


                  draft-ietf-mpls-in-ip-or-gre-03.txt

Status of this Memo

   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

   In various applications of MPLS, label stacks with multiple entries
   are used.  In some cases, it is possible to replace the top label of
   the stack with an IP-based encapsulation, thereby enabling the
   application to run over networks which do not have MPLS enabled in
   their core routers.  This draft specifies two IP-based
   encapsulations, MPLS-in-IP, and MPLS-in-GRE (Generic Routing
   Encapsulation).  Each of these is applicable in some circumstances.





Worster, et al.                                                 [Page 1]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003




Table of Contents

    1      Specification of Requirements  ..........................   2
    2      Motivation  .............................................   2
    3      Encapsulation in IP  ....................................   3
    4      Encapsulation in GRE  ...................................   4
    5      Common Procedures  ......................................   4
    5.1    Fragmentation, Reassembly, and MTU  .....................   5
    5.2    TTL  ....................................................   5
    5.3    EXP and DSCP fields  ....................................   6
    6      Applicability  ..........................................   6
    7      IANA Considerations  ....................................   6
    8      Security Considerations  ................................   7
    9      Intellectual Property Notice  ...........................   7
   10      Copyright Notice  .......................................   8
   11      Acknowledgments  ........................................   8
   12      Normative References  ...................................   8
   13      Informative References  .................................   9
   14      Author Information  .....................................   9






1. Specification of Requirements

   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.


2. Motivation

   In many applications of MPLS, packets traversing an MPLS backbone
   carry label stacks with more than one label.  As described in
   [RFC3031], section 3.15, each label represents a Label Switched Path
   (LSP).  For each such LSP, there is a Label Switching Router (LSR)
   which is the "LSP Ingress", and an LSR which is the "LSP Egress".  If
   LSRs A and B are the Ingress and Egress, respectively, of the LSP
   corresponding to a packet's top label, then A and B are adjacent LSRs
   on the LSP corresponding to the packet's second label (i.e., the
   label immediately beneath the top label)

   The purpose (or one of the purposes) of the top label is to get the
   packet delivered from A to B, so that B can further process the



Worster, et al.                                                 [Page 2]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


   packet based on the second label.  In this sense, the top label
   serves as an encapsulation header for the rest of the packet.  In
   some cases the top label can be replaced, without loss of
   functionality, by other sorts of encapsulation headers.  For example,
   the top label could be replaced by an IP header or a Generic Routing
   Encapsulation (GRE) header.  As the encapsulated packet would still
   be an MPLS packet, the result is an MPLS-in-IP or MPLS-in-GRE
   encapsulation.

   With these encapsulations, it is possible for two LSRs that are
   adjacent on an LSP to be separated by an IP network, even if that IP
   network does not provide MPLS.


3. Encapsulation in IP

   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 [RFC791] and [RFC2460] 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
                [RFC3032].

          Message Body
                This field contains one MPLS message body.



   The Protocol Number field in an IPv4 header and the Next Header field



Worster, et al.                                                 [Page 3]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


   in an IPv6 are set as follows:

     - [value to be assigned by IANA]  indicates an MPLS unicast packet,

     - [value to be assigned by IANA] indicates an MPLS multicast
       packet.  (The use of the MPLS-in-IP encapsulation for MPLS
       multicast packets is for further study.)

   Following the IP header is an MPLS packet, as specified in [RFC3032].
   This encapsulation causes MPLS packets to be sent through "IP
   tunnels".  When a packet is received by the tunnel's receive
   endpoint, the receive endpoint decapsulates the MPLS packet by
   removing the IP header.  The packet is then processed as a received
   MPLS packet whose "incoming label" [RFC3031] is the topmost label of
   the decapsulated packet.



4. Encapsulation in GRE

   The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE
   [RFC2784].  The packet then consists of an IP header followed by a
   GRE header followed by an MPLS label stack as specified in [RFC3032].
   The protocol type field in the GRE header MUST be set to the
   Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848).  The
   optional GRE checksum, key [RFC2890] and sequence number [RFC2890]
   fields MUST NOT be used.

   This encapsulation causes MPLS packets to be sent through "GRE
   tunnels". When a packet is received by the tunnel's receive endpoint,
   the receive endpoint decapsulates the MPLS packet by removing the IP
   header and the GRE header.  The packet is then processed as a
   received MPLS packet whose "incoming label" [RFC3031] is the topmost
   label of the decapsulated packet.


5. Common Procedures

   Certain procedures are common to both the MPLS-in-IP and the MPLS-
   in-GRE encapsulations.  In the following, the encapsulator, whose
   address appears in the IP source address field of the encapsulating
   IP header,  is known as the "tunnel head".  The decapsulator, whose
   address appears in the IP destination address field of the
   decapsulating IP header, is known as the "tunnel tail".







Worster, et al.                                                 [Page 4]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


5.1. Fragmentation, Reassembly, and MTU

   If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to
   "ordinary" IP fragmentation), it would have to be be reassembled by
   the tunnel tail before the contained MPLS packet could be
   decapsulated.  To avoid the need for the tunnel tail to perform
   reassembly, the tunnel head MUST set the Don't Fragment flag of the
   encapsulating IPv4 header.

   The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each
   MPLS-in-IP and MPLS-in-GRE tunnel.

   The tunnel head MUST maintain a Tunnel MTU value for each MPLS-in-IP
   or MPLS-in-GRE tunnel. This is the minimum of (a) an administratively
   configured value, and, if known, (b) the discovered Path MTU value
   minus the encapsulation overhead.

   If the tunnel head receives, for encapsulation, an MPLS packet whose
   size exceeds the Tunnel MTU, that packet MUST be discarded.

   In some cases, the tunnel head receives, for encapsulation, an IP
   packet, which it first encapsulates in MPLS and then encapsulates in
   MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
   reachable from the tunnel head, and if the result of encapsulating
   the packet in MPLS would be a packet whose size exceeds the Tunnel
   MTU, then the value which the tunnel head SHOULD use for the purposes
   of fragmentation and PMTU discovery outside the tunnel is the Tunnel
   MTU value minus the size of the MPLS sencapsulation.


5.2. TTL

   The tunnel head MAY place the TTL from the MPLS label stack into the
   encapsulating IP header.  The tunnel tail MAY place the TTL from the
   encapsulating IP header into the MPLS header, but only if that does
   not cause the TTL value in the MPLS header to become larger.

   Whether such modifications are made, and the details of how they are
   made, will depend on the configuration of the tunnel tail and the
   tunnel head.











Worster, et al.                                                 [Page 5]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


5.3. EXP and DSCP fields

   The tunnel head MAY consider the EXP field of the encapsulated MPLS
   packet when setting the DSCP field of the encapsulating IP header.
   The tunnel tail MAY modify the EXP field of the encapsulated MPLS
   packet, based on consideration of the DSCP field of the encapsulating
   IP header.

   Whether such modifications are made, and the details of how they are
   made, will depend on the configuration of the tunnel tail and the
   tunnel head.


6. Applicability

   The MPLS-in-IP encapsulation is the more efficient, and would
   generally be regarded as preferable, other things being equal.  There
   are however some situations in which the MPLS-in-GRE encapsulation
   may be used:

     - Two routers are "adjacent" over a GRE tunnel that exists for some
       reason that is outside the scope of this document, and those two
       routers need to send MPLS packets over that adjacency.  As all
       packets sent over this adjacency must have a GRE encapsulation,
       the MPLS-in-GRE encapsulation is more efficient than the
       alternative, which would be an MPLS-in-IP encapsulation which is
       then encapsulated in GRE.

     - Implementation considerations may dictate the use of MPLS-in-GRE.
       For example, some hardware device might only be able to handle
       GRE encapsulations in its fastpath.


7. IANA Considerations

   The MPLS-in-IP encapsulation requires that IANA allocate two IP
   Protocol Numbers, as described in section 3.  No future IANA actions
   will be required.  The MPLS-in-GRE encapsulation does not require any
   IANA action.












Worster, et al.                                                 [Page 6]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


8. Security Considerations

   MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec.  When
   using IPsec, the tunnel head and the tunnel tail should be treated as
   the endpoints of a Security Association.   The MPLS-in-IP or MPLS-
   in-GRE encapsulated packets should be considered as originating at
   the tunnel head and as being destined for the tunnel tail; IPsec
   transport mode should thus be used. Key distribution may be done
   either manually or automatically.

   If the tunnels are not secured using IPsec, then some other method
   should be used to ensure that packets are decapsulated and forwarded
   by the tunnel tail only if those packets were encapsulated by the
   tunnel head.  This can be done by address filtering at the boundaries
   of an administrative domain.  When the tunnel head and the tunnel
   tail are not in the same domain, this may become difficult, and it
   can even become impossible if the packets must traverse the public
   Internet.


9. Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.










Worster, et al.                                                 [Page 7]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


10. Copyright Notice

   "Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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."


11. Acknowledgments

   This specification combines a draft on encapsulating MPLS in IP, by
   Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew G.
   Malis, and Rick Wilder, with a draft on encapsulating MPLS in GRE, by
   Yakov Rekhter, Daniel Tappan, and Eric Rosen.  The current authors
   wish to thank all these authors for their contribution.  We also
   think Mark Duffy and Scott Bradner for their comments.


12. Normative References

   [RFC791] "Internet Protocol," J. Postel, Sep 1981

   [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November
   1990

   [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li,
   S. Hanks, D. Meyer, P. Traina, March 2000



Worster, et al.                                                 [Page 8]

Internet Draft    draft-ietf-mpls-in-ip-or-gre-03.txt     September 2003


   [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A.
   Viswanathan, R. Callon, January 2001

   [RFC3032] "MPLS Label Stack Encoding",  E. Rosen, D. Tappan, G.
   Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001


13. Informative References

   [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.
   Deering and R. Hinden, RFC 2460,Dec 1998

   [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety,
   August 2000



14. Author Information


      Tom Worster
      Email: fsb@thefsb.org



      Yakov Rekhter
      Juniper Networks, Inc.
      1194 N. Mathilda Ave.
      Sunnyvale, CA 94089
      Email: yakov@juniper.net



      Eric Rosen
      Cisco Systems, Inc.
      1414 Massachusetts Avenue
      Boxborough, MA 01719
      Email: erosen@cisco.com













Worster, et al.                                                 [Page 9]


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