[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 RFC 4950
MPLS Working Group
INTERNET DRAFT Ron Bonica
July 1999 MCI WorldCom
Expires January 2000 Daniel C. Tappan
Cisco Systems
Der-Hwa Gan
Juniper Networks
ICMP Extensions for MultiProtocol Label Switching
draft-ietf-mpls-icmp-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC-2026].
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.
1. Abstract
The current memo proposes extensions to ICMP that permit LSRs to
append MPLS information to ICMP messages.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in [RFC-2119].
3. Introduction
Routers and destination hosts use the Internet Control Message
Protocol (ICMP) [RFC-792] to convey control information to source
hosts. Network operators use this information to detect and diagnose
Layer 3 routing problems.
ICMP Extensions for MPLS July 1999
When a router receives an undeliverable IP datagram, it can send an
ICMP message to the host that originated the datagram. The ICMP
message indicates why the datagram could not be delivered. It also
contains the IP header and leading payload bytes of the
undeliverable datagram.
MPLS Label Switching Routers (LSRs) also use ICMP to convey control
information to source hosts. Sections 2.3 and 2.4 of [ENCODE]
describe the interaction between MPLS and ICMP.
When an LSR receives an undeliverable MPLS labeled datagram, it
removes the entire MPLS label stack, exposing the encapsulated IP
datagram. The router then submits the IP datagram to a network-
forwarding module for error processing. Error processing can include
ICMP message generation.
Although the ICMP message contains the non-delivery reason, IP
header and leading payload bytes, it contains no information
regarding the MPLS label stack that encapsulated the datagram when
it arrived at the LSR.
The current memo proposes extensions to ICMP that permit LSRs to
append MPLS label stack information to the ICMP message body. Hence,
ICMP messages regarding undeliverable MPLS encapsulated datagrams
SHOULD include the MPLS label stack, as it arrived at the router
that is sending the ICMP message. The ICMP message MUST also include
the IP header and leading payload bytes of the undeliverable
datagram.
Network operators will use this information to detect and diagnose
MPLS problems.
4. Motivation
ICMP extensions defined in the current memo support enhancements to
TRACEROUTE. The enhanced TRACEROUTE, like older TRACEROUTE
implementations, reports each IP router and LSR that a datagram
visits en route to its destination. The enhanced TRACEROUTE differs
from older implementations in that it indicates which nodes were
visited while traversing a Label Switched Path (LSP).
Figure 1 contains sample output from an enhanced TRACEROUTE
implementation.
ICMP Extensions for MPLS July 1999
>Traceroute 166.45.2.74
traceroute to 166.45.2.74, 30 hops max, 40 byte packets
1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms
2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms
mplsLabel1=2001 mplsExpBits1=0
3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms
mplsLabel1=2002 mplsExpBits1=0
4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms
mplsLabel1=2003 mplsExpBits1=0
5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms
6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms
Figure 1. Enhanced TRACEROUTE sample output
5. Disclaimer
The current memo does not define the general relationship between
ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this
relationship.
Specifically, this document defers to [ENCODE] with respect to the
following issues:
- conditions upon which LSRs emit ICMP messages
- handling of ICMP messages bound for hosts that are identified
by private addresses
The current memo does not define encapsulation specific TTL
manipulation procedures. It defers to Section 10 of [MPLSATM] and
Section 5.4 of [MPLSFRAME] in this matter.
When encapsulation specific TTL manipulation procedures defeat the
basic TRACEROUTE mechanism, they will also defeat enhanced
TRACEROUTE implementations.
6. Backward Compatibility
ICMP extensions proposed in this document MUST be backward
compatible with the syntax described in RFC-792. Extensions proposed
in this memo MUST NOT change or deprecate any field defined in RFC-
792.
ICMP Extensions for MPLS July 1999
7. Formal Syntax
This section describes a data structure that can be appended to the
following ICMP message types:
1) Destination Unreachable
2) Time Exceeded
3) Parameter Problem
4) Source Quench
5) Redirect
The above listed ICMP message types specify a fixed length of 56
bytes. When the data structure defined in this section is appended
to an ICMP message, the ICMP _total length_ field MUST equal the
data structure length plus 56.
The data structure defined in this section consists of a common
header followed by object instances. Each object instance consists
of an object header plus contents.
Currently, only one object class is defined. This object class
contains an entire MPLS label stack, formatted exactly as it was
when it arrived at the LSR that sends the ICMP message.
In the future, additional object classes may be defined.
7.1 Common Header
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | (Reserved) | Checksum |
+-------------+-------------+-------------+-------------+
The fields in the common header are as follows:
Vers: 4 bits
ICMP extension version number. This is version 1.
Checksum: 16 bits
The one's complement of the one's complement sum of the data
structure, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value means that
no checksum was transmitted.
If the checksum field contains a value other than described
above, bytes 56 and beyond of the ICMP message do not contain
the data structure described by this memo. These bytes may
ICMP Extensions for MPLS July 1999
contain an extended ICMP payload as described in Section 4.3.2.3
of [RFC-1812].
Reserved:
Must be set to 0.
7.2 Object Header
Every object consists of one or more 32-bit words with a one-word
header, with the following format:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
An object header has the following fields:
Length: 16 bits
Length of the object, measured in bytes, including the object
header and object contents.
Class-Num: 8 bits
Identifies object class. Currently, the only one object class
is defined. This is the MPLS Stack Entry Object.
C-Type: 8 bits
Identifies object sub-type. Currently, only one object sub-type
is defined.
7.3 MPLS Stack Entry Object Class
An instance of the MPLS Entry Object class represents the entire
MPLS label stack, formatted exactly as it was when it arrived at the
LSR that sends the ICMP message.
ICMP Extensions for MPLS July 1999
In the illustration below, bytes 0-3 depict the first member of the
MPLS label stack. Each remaining member of the MPLS label stack is
represented by another 4 bytes that share the same format.
Syntax follows:
MPLS Stack Entry Class = 1, C-Type = 1.
0 1 2 3
+-------------+-------------+-------------+-------------+
| Label |EXP |S| TTL |
+-------------+-------------+-------------+-------------+
| |
// Remaining MPLS Stack Entries //
| |
+-------------+-------------+-------------+-------------+
Label: 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
8.Security Considerations
This memo presents no security considerations beyond those already
presented by current ICMP applications (e.g., traceroute).
9. References
[ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", Internet Draft <draft-ietf-mpls-arch-
02.txt>, July, 1998
[ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D.,
Fedorkow, G., Li, T., Conta, A., _MPLS Stack Encoding_, Internet
Draft, <draft-ietf-mpls-label-encapse-03.txt>, September 1998.
[FRAME], Callon, R., Doolan, P., Feldman, N., Fredette, A.,
Swallow, G., and A. Viswanathan, "A Framework for Multiprotocol
Label Switching", Internet Draft <draft-ietf-mpls-framework-02.txt>,
November 1997.
[MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
Rosen, E., Swallow, G, _MPLS using ATM VC Switching_, <draft-ietf-
mpls-atm-01.txt>, November, 1998.
[MPLSFRAME], Conta, A., Doolan, P., Malis, A., _Use of Label
Switching on Frame Relay Networks_, <draft-ietf-mpls-fr-03.txt>,
November, 1998.
ICMP Extensions for MPLS July 1999
[RFC-792], Postel, J., _Internet Control Message Protocol_, RFC 792,
ISI, September 1981.
[RFC-1812], Baker, F., _Requirements for IP Version 4 Routers_, RFC
1812, June 1995.
[RFC-2026], Bradner, S., _Internet Standards Process _ Revision 3_,
RFC 2026, Harvard University, October 1996.
[RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997
10. Author's Addresses
Ronald P. Bonica
MCI WorldCom
2100 Reston Parkway
Reston, Virginia, U.S.A. 20191
Phone: +1 703 715 7176
Email: rbonica@mci.net
Daniel C. Tappan
Cisco Systems
250 Apollo Drive
Chelmsford, Massachusetts, 01824
Email: tappan@cisco.com
Der-Hwa Gan
Juniper Networks
385 Ravendale Drive
Mountain View, California 94043
Email: dhg@juniper.net
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/