Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
RFC 4023

 
Document Type RFC - Proposed Standard (March 2005; No errata)
Updated by RFC 5332
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state WG Document
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4023 (Proposed Standard)
Telechat date
Responsible AD Alex Zinin
Send notices to <swallow@cisco.com>, <loa@pi.se>, erosen@cisco.com

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                         T. Worster
Request for Comments: 4023                                Motorola, Inc.
Category: Standards Track                                     Y. Rekhter
                                                  Juniper Networks, Inc.
                                                           E. Rosen, Ed.
                                                     Cisco Systems, Inc.
                                                              March 2005

    Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Various applications of MPLS make use of label stacks with multiple
   entries.  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 that do not have MPLS enabled in
   their core routers.  This document 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.             Standards Track                     [Page 1]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

Table of Contents

   1.  Motivation  ..................................................  2
   2.  Specification of Requirements  ...............................  3
   3.  Encapsulation in IP  .........................................  3
   4.  Encapsulation in GRE  ........................................  4
   5.  Common Procedures  ...........................................  5
       5.1.  Preventing Fragmentation and Reassembly  ...............  5
       5.2.  TTL or Hop Limit  ......................................  6
       5.3.  Differentiated Services  ...............................  7
   6.  Applicability  ...............................................  7
   7.  IANA Considerations  .........................................  8
   8.  Security Considerations  .....................................  8
       8.1.  Securing the Tunnel with IPsec .........................  8
       8.2.  In the Absence of IPsec  ............................... 10
   9.  Acknowledgements ............................................. 11
   10. Normative References  ........................................ 11
   11. Informative References  ...................................... 12
   Authors' Addresses ............................................... 13
   Full Copyright Statement ......................................... 14

1.  Motivation

   In many applications of MPLS, packets traversing an MPLS backbone
   carry label stacks with more than one label.  As described in section
   3.15 of [RFC3031], each label represents a Label Switched Path (LSP).
   For each LSP, there is a Label Switching Router (LSR) that is the
   "LSP Ingress", and an LSR that 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
   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, other sorts of encapsulation headers can replace the top
   label without loss of functionality.  For example, an IP header or a
   Generic Routing Encapsulation (GRE) header could replace the top
   label.  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.

Worster, et al.             Standards Track                     [Page 2]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

   To use either of these encapsulations, the encapsulating LSR must
   know

      -  the IP address of the decapsulating LSR, and

      -  that the decapsulating LSR actually supports the particular
Show full document text