draft-ietf-mpls-in-ip-or-gre-02.txt   draft-ietf-mpls-in-ip-or-gre-03.txt 
Network Working Group Tom Worster Network Working Group Tom Worster
Internet Draft Internet Draft
Expiration Date: February 2004 Expiration Date: March 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.
August 2003 September 2003
Encapsulating MPLS in IP or GRE Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
draft-ietf-mpls-in-ip-or-gre-02.txt draft-ietf-mpls-in-ip-or-gre-03.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 1, line 45 skipping to change at page 1, line 45
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
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 (Generic Routing
applicable in some circumstances. Encapsulation). Each of these is applicable in some circumstances.
Table of Contents Table of Contents
1 Specification of Requirements .......................... 2 1 Specification of Requirements .......................... 2
2 Motivation ............................................. 2 2 Motivation ............................................. 2
3 Encapsulation in IP .................................... 3 3 Encapsulation in IP .................................... 3
4 Encapsulation in GRE ................................... 4 4 Encapsulation in GRE ................................... 4
5 Common Procedures ...................................... 4 5 Common Procedures ...................................... 4
5.1 Fragmentation, Reassembly, and MTU ..................... 5 5.1 Fragmentation, Reassembly, and MTU ..................... 5
5.2 TTL .................................................... 5 5.2 TTL .................................................... 5
5.3 EXP and DSCP fields .................................... 6 5.3 EXP and DSCP fields .................................... 6
6 Applicability .......................................... 6 6 Applicability .......................................... 6
7 IANA Considerations .................................... 6 7 IANA Considerations .................................... 6
8 Security Considerations ................................ 7 8 Security Considerations ................................ 7
9 Acknowledgments ........................................ 7 9 Intellectual Property Notice ........................... 7
10 References ............................................. 7 10 Copyright Notice ....................................... 8
11 Author Information ..................................... 8 11 Acknowledgments ........................................ 8
12 Normative References ................................... 8
13 Informative References ................................. 9
14 Author Information ..................................... 9
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Motivation 2. Motivation
In many applications of MPLS, packets traversing an MPLS backbone In many applications of MPLS, packets traversing an MPLS backbone
skipping to change at page 3, line 5 skipping to change at page 3, line 8
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)
The purpose (or one of the purposes) of the top label is to get the 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 delivered from A to B, so that B can further process the
packet based on the second label. In this sense, the top label packet based on the second label. In this sense, the top label
serves as an encapsulation header for the rest of the packet. In serves as an encapsulation header for the rest of the packet. In
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 Generic Routing
the encapsulated packet would still be an MPLS packet, the result is Encapsulation (GRE) header. As the encapsulated packet would still
an MPLS-in-IP or MPLS-in-GRE encapsulation. 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 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.
3. Encapsulation in IP 3. Encapsulation in IP
MPLS-in-IP messages have the following format: MPLS-in-IP messages have the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 24 skipping to change at page 7, line 24
If the tunnels are not secured using IPsec, then some other method If the tunnels are not secured using IPsec, then some other method
should be used to ensure that packets are decapsulated and forwarded should be used to ensure that packets are decapsulated and forwarded
by the tunnel tail only if those packets were encapsulated by the by the tunnel tail only if those packets were encapsulated by the
tunnel head. This can be done by address filtering at the boundaries tunnel head. This can be done by address filtering at the boundaries
of an administrative domain. When the tunnel head and the tunnel of an administrative domain. When the tunnel head and the tunnel
tail are not in the same domain, this may become difficult, and it tail are not in the same domain, this may become difficult, and it
can even become impossible if the packets must traverse the public can even become impossible if the packets must traverse the public
Internet. Internet.
9. Acknowledgments 9. Intellectual Property Notice
This draft is a combination of two previous drafts: 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.
- draft-worster-mpls-in-ip, by Tom Worster, Paul Doolan, Yasuhiro The IETF invites any interested party to bring to its attention any
Katsube, Tom K. Johnson, Andrew G. Malis, and Rick Wilder 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.
- draft-rekhter-mpls-over-gre, by Yakov Rekhter, Daniel Tappan, and 10. Copyright Notice
Eric Rosen
The current authors wish to thank all these authors for their "Copyright (C) The Internet Society (date). All Rights Reserved.
contribution. We also think Mark Duffy and Scott Bradner for their
comments.
10. References 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.
[RFC791] "Internet Protocol," J. Postel, Sep 1981 The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
[RFC2460]"Internet Protocol, Version 6 (IPv6) Specification," S. This document and the information contained herein is provided on an
Deering and R. Hinden, RFC 2460,Dec 1998 "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 [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,
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
11. Author Information 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 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/