draft-ietf-mpls-in-ip-or-gre-01.txt   draft-ietf-mpls-in-ip-or-gre-02.txt 
Network Working Group Tom Worster Network Working Group Tom Worster
Internet Draft Internet Draft
Expiration Date: January 2004 Expiration Date: February 2004
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
Eric C. Rosen, editor Eric C. Rosen, editor
Cisco Systems, Inc. Cisco Systems, Inc.
July 2003 August 2003
Encapsulating MPLS in IP or GRE Encapsulating MPLS in IP or GRE
draft-ietf-mpls-in-ip-or-gre-01.txt draft-ietf-mpls-in-ip-or-gre-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
In various applications of MPLS, label stacks with multiple entries In various applications of MPLS, label stacks with multiple entries
are used. In some cases, it is possible to replace the top label of are used. In some cases, it is possible to replace the top label of
the stack with an IP-based encapsulation, thereby enabling the the stack with an IP-based encapsulation, thereby enabling the
application to run over networks which do not have MPLS enabled in application to run over networks which do not have MPLS enabled in
their core routers. This draft specifies two IP-based their core routers. This draft specifies two IP-based
encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is
applicable in some circumstances. applicable in some circumstances.
Table of Contents Table of Contents
1 Motivation ............................................. 2 1 Specification of Requirements .......................... 2
2 Encapsulation in IP .................................... 3 2 Motivation ............................................. 2
3 Encapsulation in GRE ................................... 4 3 Encapsulation in IP .................................... 3
4 Common Procedures ...................................... 4 4 Encapsulation in GRE ................................... 4
4.1 Fragmentation, Reassembly, and MTU ..................... 4 5 Common Procedures ...................................... 4
4.2 TTL .................................................... 5 5.1 Fragmentation, Reassembly, and MTU ..................... 5
4.3 EXP and DSCP fields .................................... 5 5.2 TTL .................................................... 5
5 Applicability .......................................... 5 5.3 EXP and DSCP fields .................................... 6
6 Security Considerations ................................ 6 6 Applicability .......................................... 6
7 Acknowledgments ........................................ 6 7 IANA Considerations .................................... 6
8 References ............................................. 6 8 Security Considerations ................................ 7
9 Author Information ..................................... 7 9 Acknowledgments ........................................ 7
10 References ............................................. 7
11 Author Information ..................................... 8
1. Motivation 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 In many applications of MPLS, packets traversing an MPLS backbone
carry label stacks with more than one label. As described in carry label stacks with more than one label. As described in
[RFC3031], section 3.15, each label represents a Label Switched Path [RFC3031], section 3.15, each label represents a Label Switched Path
(LSP). For each such LSP, there is a Label Switching Router (LSR) (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 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 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 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 on the LSP corresponding to the packet's second label (i.e., the
label immediately beneath the top label) label immediately beneath the top label)
skipping to change at page 3, line 5 skipping to change at page 3, line 13
some cases the top label can be replaced, without loss of some cases the top label can be replaced, without loss of
functionality, by other sorts of encapsulation headers. For example, functionality, by other sorts of encapsulation headers. For example,
the top label could be replaced by an IP header or a GRE header. As the top label could be replaced by an IP header or a GRE header. As
the encapsulated packet would still be an MPLS packet, the result is the encapsulated packet would still be an MPLS packet, the result is
an MPLS-in-IP or MPLS-in-GRE encapsulation. an MPLS-in-IP or MPLS-in-GRE encapsulation.
With these encapsulations, it is possible for two LSRs that are 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 adjacent on an LSP to be separated by an IP network, even if that IP
network does not provide MPLS. network does not provide MPLS.
2. Encapsulation in IP 3. Encapsulation in IP
MPLS-in-IP messages have the following format: MPLS-in-IP messages have the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Header | | IP Header |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MPLS Label Stack | | MPLS Label Stack |
skipping to change at page 3, line 39 skipping to change at page 4, line 5
MPLS Label Stack MPLS Label Stack
This field contains an MPLS Label Stack as defined in This field contains an MPLS Label Stack as defined in
[RFC3032]. [RFC3032].
Message Body Message Body
This field contains one MPLS message body. This field contains one MPLS message body.
The Protocol Number field in an IPv4 header and the Next Header field The Protocol Number field in an IPv4 header and the Next Header field
in an IPv6 are set as follows: in an IPv6 are set as follows:
- X indicates an MPLS unicast packet, - [value to be assigned by IANA] indicates an MPLS unicast packet,
- Y indicates an MPLS multicast packet. (The use of the MPLS-in-IP - [value to be assigned by IANA] indicates an MPLS multicast
encapsulation for MPLS multicast packets is for further study.) 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]. Following the IP header is an MPLS packet, as specified in [RFC3032].
This encapsulation causes MPLS packets to be sent through "IP This encapsulation causes MPLS packets to be sent through "IP
tunnels". When a packet is received by the tunnel's receive tunnels". When a packet is received by the tunnel's receive
endpoint, the receive endpoint decapsulates the MPLS packet by endpoint, the receive endpoint decapsulates the MPLS packet by
removing the IP header. The packet is then processed as a received removing the IP header. The packet is then processed as a received
MPLS packet whose "incoming label" [RFC3031] is the topmost packet of MPLS packet whose "incoming label" [RFC3031] is the topmost label of
the decapsulated packet. the decapsulated packet.
3. Encapsulation in GRE 4. Encapsulation in GRE
The MPLS-in-GRE encapsulation encapsulates an MPLS packet 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 [RFC2784]. The packet then consists of an IP header followed by a
GRE header followed by an MPLS label stack as specified in [RFC3032]. 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 The protocol type field in the GRE header MUST be set to the
Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848). The Ethertype value for MPLS Unicast (0x8847) or Multicast (0x8848). The
optional GRE checksum, key [RFC2890] and sequence number [RFC2890] optional GRE checksum, key [RFC2890] and sequence number [RFC2890]
fields MUST NOT be used. fields MUST NOT be used.
This encapsulation causes MPLS packets to be sent through "GRE This encapsulation causes MPLS packets to be sent through "GRE
tunnels". When a packet is received by the tunnel's receive endpoint, tunnels". When a packet is received by the tunnel's receive endpoint,
the receive endpoint decapsulates the MPLS packet by removing the IP the receive endpoint decapsulates the MPLS packet by removing the IP
header and the GRE header. The packet is then processed as a header and the GRE header. The packet is then processed as a
received MPLS packet whose "incoming label" [RFC3031] is the topmost received MPLS packet whose "incoming label" [RFC3031] is the topmost
packet of the decapsulated packet. label of the decapsulated packet.
4. Common Procedures 5. Common Procedures
Certain procedures are common to both the MPLS-in-IP and the MPLS- Certain procedures are common to both the MPLS-in-IP and the MPLS-
in-GRE encapsulations. In the following, the encapsulator, whose in-GRE encapsulations. In the following, the encapsulator, whose
address appears in the IP source address field of the encapsulating address appears in the IP source address field of the encapsulating
IP header, is known as the "tunnel head". The decapsulator, whose IP header, is known as the "tunnel head". The decapsulator, whose
address appears in the IP destination address field of the address appears in the IP destination address field of the
decapsulating IP header, is known as the "tunnel tail". decapsulating IP header, is known as the "tunnel tail".
4.1. Fragmentation, Reassembly, and MTU 5.1. Fragmentation, Reassembly, and MTU
If an MPLS-in-IP or MPLS-in-GRE packet were to get fragmented (due to 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 "ordinary" IP fragmentation), it would have to be be reassembled by
the tunnel tail before the contained MPLS packet be decapsulated. To the tunnel tail before the contained MPLS packet could be
avoid the need for the tunnel tail to perform reassembly, the tunnel decapsulated. To avoid the need for the tunnel tail to perform
head MUST set the Don't Fragment flag of the encapsulating IPv4 reassembly, the tunnel head MUST set the Don't Fragment flag of the
header. encapsulating IPv4 header.
The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each The tunnel head SHOULD perform Path MTU Discovery [RFC1191] over each
MPLS-in-IP and MPLS-in-GRE tunnel. MPLS-in-IP and MPLS-in-GRE tunnel.
The tunnel head MUST maintain a Tunnel MTU value for each MPLS-in-IP 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 or MPLS-in-GRE tunnel. This is the minimum of (a) an administratively
configured value, and, if known, (b) the discovered Path MTU value configured value, and, if known, (b) the discovered Path MTU value
minus the encapsulation overhead. minus the encapsulation overhead.
If the tunnel head receives, for encapsulation, an MPLS packet whose If the tunnel head receives, for encapsulation, an MPLS packet whose
size exceeds the Tunnel MTU, that packet MUST be discarded. size exceeds the Tunnel MTU, that packet MUST be discarded.
In some cases, the tunnel head receives, for encapsulation, an IP In some cases, the tunnel head receives, for encapsulation, an IP
packet, which it first encapsulates in MPLS and then encapsulates in 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 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 this reachable from the tunnel head, and if the result of encapsulating
encapsulation would be a packet whose size exceeds the Tunnel MTU, the packet in MPLS would be a packet whose size exceeds the Tunnel
then the tunnel head SHOULD use the Tunnel MTU value for the purposes MTU, then the value which the tunnel head SHOULD use for the purposes
of fragmentation and PMTU discovery outside the tunnel. of fragmentation and PMTU discovery outside the tunnel is the Tunnel
MTU value minus the size of the MPLS sencapsulation.
4.2. TTL 5.2. TTL
The tunnel head MAY place the TTL from the MPLS label stack into the 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. The tunnel tail MAY place the TTL from the
encapsulating IP header into the MPLS header, but only if that does encapsulating IP header into the MPLS header, but only if that does
not cause the TTL value in the MPLS header to become larger. not cause the TTL value in the MPLS header to become larger.
Whether such modifications are made, and the details of how they are Whether such modifications are made, and the details of how they are
made, will depend on the configuration of the tunnel tail and the made, will depend on the configuration of the tunnel tail and the
tunnel head. tunnel head.
4.3. EXP and DSCP fields 5.3. EXP and DSCP fields
The tunnel head MAY consider the EXP field of the encapsulated MPLS The tunnel head MAY consider the EXP field of the encapsulated MPLS
packet when setting the DSCP field of the encapsulating IP header. packet when setting the DSCP field of the encapsulating IP header.
The tunnel tail MAY modify the EXP field of the encapsulated MPLS The tunnel tail MAY modify the EXP field of the encapsulated MPLS
packet, based on consideration of the DSCP field of the encapsulating packet, based on consideration of the DSCP field of the encapsulating
IP header. IP header.
Whether such modifications are made, and the details of how they are Whether such modifications are made, and the details of how they are
made, will depend on the configuration of the tunnel tail and the made, will depend on the configuration of the tunnel tail and the
tunnel head. tunnel head.
5. Applicability 6. Applicability
The MPLS-in-IP encapsulation is the more efficient, and would The MPLS-in-IP encapsulation is the more efficient, and would
generally be regarded as preferable, other things being equal. There generally be regarded as preferable, other things being equal. There
are however some situations in which the MPLS-in-GRE encapsulation are however some situations in which the MPLS-in-GRE encapsulation
may be used: may be used:
- Two routers are "adjacent" over a GRE tunnel that exists for some - Two routers are "adjacent" over a GRE tunnel that exists for some
reason that is outside the scope of this document, and those two reason that is outside the scope of this document, and those two
routers need to send MPLS packets over that adjacency. As all routers need to send MPLS packets over that adjacency. As all
packets sent over this adjacency must have a GRE encapsulation, packets sent over this adjacency must have a GRE encapsulation,
the MPLS-in-GRE encapsulation is more efficient than the the MPLS-in-GRE encapsulation is more efficient than the
alternative, which would be an MPLS-in-IP encapsulation which is alternative, which would be an MPLS-in-IP encapsulation which is
then encapsulated in GRE. then encapsulated in GRE.
- Implementation considerations may dictate the use of MPLS-in-GRE. - Implementation considerations may dictate the use of MPLS-in-GRE.
For example, some hardware device might only be able to handle For example, some hardware device might only be able to handle
GRE encapsulations in its fastpath. GRE encapsulations in its fastpath.
6. Security Considerations 7. IANA Considerations
MPLS-in-IP or MPLS-in-GRE tunnels may be secured using IPsec. If The MPLS-in-IP encapsulation requires that IANA allocate two IP
they are not secured using IPsec, then some other method should be Protocol Numbers, as described in section 3. No future IANA actions
used to ensure that packets are decapsulated and forwarded by the will be required. The MPLS-in-GRE encapsulation does not require any
tunnel tail only if those packets were encapsulated by the tunnel IANA action.
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.
7. Acknowledgments 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. Acknowledgments
This draft is a combination of two previous drafts: This draft is a combination of two previous drafts:
- draft-worster-mpls-in-ip, by Tom Worster, Paul Doolan, Yasuhiro - draft-worster-mpls-in-ip, by Tom Worster, Paul Doolan, Yasuhiro
Katsube, Tom K. Johnson, Andrew G. Malis, and Rick Wilder Katsube, Tom K. Johnson, Andrew G. Malis, and Rick Wilder
- draft-rekhter-mpls-over-gre, by Yakov Rekhter, Daniel Tappan, and - draft-rekhter-mpls-over-gre, by Yakov Rekhter, Daniel Tappan, and
Eric Rosen Eric Rosen
The current authors wish to thank all these authors for their The current authors wish to thank all these authors for their
contribution. contribution. We also think Mark Duffy and Scott Bradner for their
comments.
8. References 10. References
[RFC7915] "Internet Protocol," J. Postel, Sep 1981 [RFC791] "Internet Protocol," J. Postel, Sep 1981
[RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S. [RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S.
Deering and R. Hinden, RFC 2460,Dec 1998 Deering and R. Hinden, RFC 2460,Dec 1998
[RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November
1990 1990
[RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li,
S. Hanks, D. Meyer, P. Traina, March 2000 S. Hanks, D. Meyer, P. Traina, March 2000
[RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety, [RFC2890] "Key and Sequence Number Extensions to GRE", G. Dommety,
August 2000 August 2000
[RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A.
Viswanathan, R. Callon, January 2001 Viswanathan, R. Callon, January 2001
[RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G. [RFC3032] "MPLS Label Stack Encoding", E. Rosen, D. Tappan, G.
Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001 Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001
9. Author Information 11. Author Information
Tom Worster Tom Worster
Email: fsb@thefsb.org Email: fsb@thefsb.org
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net Email: yakov@juniper.net
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/