Internet Draft 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, July, 1998 [ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., Fedorkow, G., Li, T., Conta, A., _MPLS Stack Encoding_, Internet Draft, , 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