One document matched: draft-bonica-icmp-mpls-00.txt
MPLS
Internet Draft Ron Bonica
February 1999 MCI WorldCom
Expires August 1999 Daniel C. Tappan
Cisco Systems
ICMP Extensions for MultiProtocol Label Switching
draft-bonica-icmp-mpls-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
This memo proposes extensions to ICMP. Using these extensions,
routers can communicate additional control information to source
hosts. The additional control information describes the MPLS stack
that encapsulates an IP datagram.
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
The Internet Control Message Protocol (ICMP) is an integral part of
the Internet Protocol Suite. [RFC-792] defines ICMP semantics and
syntax.
ICMP provides a mechanism through which routers and destination
hosts communicate control information to source hosts. When a router
ICMP Extensions for MPLS February 1999
receives an undeliverable IP datagram, the router 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 bytes of the undeliverable datagram.
The most widely used Internet debugging applications, PING and
TRACEROUTE, rely upon ICMP control information.
This memo proposes extensions to ICMP. Using these extensions,
routers can communicate additional control information to source
hosts. The additional control information describes the MPLS stack
that encapsulates an incoming IP datagram.
4. Background
Sections 2.3 and 2.4 of [ENCODE] describe the interaction between
ICMP and MPLS. When a router receives an undeliverable MPLS labeled
datagram, the router 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.
The ICMP message lacks critical information. Specifically, it lacks
information regarding the state of the MPLS stack that once
encapsulated the problem datagram. This information is particularly
critical to the TRACEROUTE application.
5. Semantics
When a router generates an ICMP message regarding an MPLS labeled
datagram, the ICMP message SHOULD reflect the state of the incoming
MPLS label stack. This information facilitates MPLS aware debugging
applications (e.g., MPLS aware traceroute).
The balance of this document proposes a syntax through which routers
can append MPLS information to ICMP messages.
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 February 1999
7. Formal Syntax
This section describes a data structure that can be appended to any
fixed length ICMP message. The following ICMP messages types specify
a fixed length of 56 bytes:
1) Destination Unreachable
2) Time Exceeded
3) Parameter Problem
4) Source Quench
5) Redirect
The data structure defined in this section cannot be appended to
variable length ICMP messages. The following are variable length
ICMP message types:
1) Echo
2) Echo Reply
When the data structure defined in this section is appended to an
ICMP message, the ICMP _total length_ field should equal the data
structure length plus 56.
The data structure defined in this section consists of a common
header followed by one or more object instances. Each object
instance consists of an object header plus contents.
Currently, only one object class is defined. Each instance of this
object class represents an entry on a datagrams MPLS stack.
Assume that a router sends an ICMP message in response to an IP
datagram that arrived encapsulated in an N layer MPLS stack. The
ICMP message should include a common header plus N instances of the
MPLS label stack object class. Each instance should contain a copy
of the Label stack entry from the received packet, sequentially
starting at the topmost label.
7.1 Common Header
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | (Reserved) | Checksum |
+-------------+-------------+-------------+-------------+
| Length | (Reserved) |
+-------------+-------------+-------------+-------------+
The fields in the common header are as follows:
Vers: 4 bits
ICMP extension version number. This is version 1.
ICMP Extensions for MPLS February 1999
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.
Length: 16 bits
Length of the data structure, measured in bytes, including the
common header and variable length objects that follow.
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.
ICMP Extensions for MPLS February 1999
7.3 MPLS Stack Entry Object Class
Each instance of the MPLS Entry Object class represents an entry on
a datagrams MPLS stack. Syntax follows:
MPLS Stack Entry Class = 1, C-Type = 1.
+-------------+-------------+-------------+-------------+
| Label |Exp| | TTL |
+-------------+-------------+-------------+-------------+
| Stack Pos. | (Reserved) |
+-------------+-------------+-------------+-------------+
This object header has the following fields:
Label: 24 bits
Label value for a particular entry on the incoming MPLS label
stack
Exp: 3 bits
Experimental bit value for a particular entry on the MPLS
incoming label stack.
TTL: 8 bits
Time-to-live value from a particular entry on the incoming MPLS
label stack.
Stack Pos: 8 bits
Position of a particular entry on the incoming MPLS label
stack. Value of 0 indicates last entry on label stack (S bit
set). Value of 1 indicates next to last entry, etc.
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.
ICMP Extensions for MPLS February 1999
[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.
[RFC-792], Postel, J., _Internet Control Message Protocol_, RFC 792,
ISI, September 1981.
[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
11. 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
| PAFTECH AB 2003-2026 | 2026-04-22 06:26:53 |