MPLS Working Group
INTERNET DRAFT                                  Ron Bonica
July 1999                                       MCI WorldCom
Expires January 2000                            Daniel C. Tappan                                             R.Bonica
Internet Draft                                              MCIWorldCom
Document: draft-ietf-mpls-icmp-01.txt                          D.Tappan
                                                          Cisco Systems
                                                Der-Hwa Gan
                                                                  D.Gan
                                                       Juniper Networks
                                                          December 1999

           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 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.
   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 Label
   Switching Routers 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" in
   this document 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.

Bonica, Tappan, Hwa     Draft-Expires May 2000                       1
   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 octets of the
   undeliverable datagram. "original
   datagram".

   In this document, the term "original datagram" refers to the
   datagram to which the ICMP message is a response.

   MPLS Label Switching Routers (LSRs) (LSR) 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 encapsulated datagram, it
   removes the entire MPLS label stack, exposing the previously
   encapsulated IP datagram. The router LSR then submits the IP datagram to a network-
   forwarding
   network-forwarding module for error processing. Error processing can
   include ICMP message generation.

   Although the

   The ICMP message indicates why the original datagram could not be
   delivered. It also contains the non-delivery reason, IP header and leading payload bytes, it contains octets of the
   original datagram.

   The ICMP message, however, includes no information regarding the
   MPLS label stack that encapsulated the original datagram when it
   arrived at the LSR. This omission is significant because the LSR
   would have routed the original datagram based upon information
   contained by the MPLS label stack.

   The current memo proposes extensions to ICMP that permit LSRs an LSR to
   append MPLS label stack information to the ICMP message body. Hence, messages. 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
   octets of the undeliverable original datagram.

   Network operators will use this information to detect and diagnose
   MPLS routing
   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
   indicates which nodes the original datagram
   visits visited en route to its
   ultimate destination. The enhanced TRACEROUTE It differs from older implementations in that
   it also indicates which nodes were
   visited while traversing a Label Switched Path (LSP). the original datagrams MPLS encapsulation status
   as it arrived at each node.

   Figure 1 contains sample output from an enhanced TRACEROUTE
   implementation.

 Bonica,Tappan,Gan      Draft-Expires May 2000                       2
        >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 an LSR emits 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

   The current memo does not address extensions proposed in this document MUST to ICMPv6. These should
   be backward
   compatible with the syntax described in RFC-792. Extensions proposed
   in this memo MUST NOT change or deprecate any field defined addressed in RFC-
   792.

7. a separate draft.

6. Formal Syntax

   This section describes defines a data structure that an LSR can append to
   selected ICMP messages. The data structure contains the MPLS label
   stack that encapsulated the original datagram when it arrived at the
   LSR.

   The data structure defined herein can be appended to the following
   ICMP message types:

 Bonica,Tappan,Gan      Draft-Expires May 2000                       3
   1) Destination Unreachable
   2) Time Exceeded
   3) Parameter Problem
   4) Source Quench
   5) Redirect

   The above listed

   According to RFC-792, the final field contained by each of these
   ICMP message types specify a fixed length reflects the IP header and leading 64 bits of the
   original datagram. [RFC-1812] recommends that this final field be
   extended to include as much of 56
   bytes. the original datagram as possible.

   When an LSR appends the data structure defined in this section is appended herein to an ICMP
   message, the ICMP _total length_ final field of the ICMP message body MUST equal contain the
   data structure length plus 56.

   The data structure defined in this section consists
   first 128 octets of a common the original datagram. At least 20 of these 128
   octets represent the IP header of the original datagram.

   If the original datagram was shorter than 128 octets, the final
   field MUST be padded with 0's.

   When an LSR appends the data structure defined herein to an ICMP
   message, the ICMP "total length" MUST be equal to the data structure
   length plus 156. The first octet of the data structure must be
   displaced 156 octets from the beginning of the ICMP message.

   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 two object class is classes are defined. This One object class contains
   an entire MPLS label stack, formatted exactly as it was when it
   arrived at the LSR that sends the ICMP message. The other contains
   some portion of the original datagram that could not be included in
   the final field of the ICMP message body (i.e., the octet 129 and
   beyond).

   Both object classes are optional.

   In the future, additional object classes may be defined.

7.1

6.1 Common Header

          0             1            2              3
   +-------------+-------------+-------------+-------------+
   | Vers |     (Reserved)     |          Checksum         |
   +-------------+-------------+-------------+-------------+

   The fields in the common header are as follows:

 Bonica,Tappan,Gan      Draft-Expires May 2000                       4
   Vers: 4 bits

   ICMP extension version number.

   This is version 1. 2.

   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 does not contain include the data structure extensions described by in this
   memo. These bytes may
       contain an extended This, however, does not imply that the ICMP payload as described message is
   malformed. It may be in Section 4.3.2.3
       of [RFC-1812]. strict compliance with RFC-1812.

   Reserved: Must be set to 0.

7.2

6.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, octets, 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

 Bonica,Tappan,Gan      Draft-Expires May 2000                       5

6.3 MPLS Stack Entry Object Class

   An

   A single 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. message

   In the illustration below, bytes octets 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 octets 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

6.4 Extended Payload Object Class

   An instance of the Extended Payload Object class represents some
   portion of the original datagram that could not be fit in the final
   field of the ICMP message body (i.e., octets beyond 128).

   Syntax follows:

   MPLS Stack Entry Class = 2, C-Type = 1.

           0             1             2            3
   +-------------+-------------+-------------+-------------+
   |                                                       |
   |       // Remaining MPLS Stack Entries //              |
   |                                                       |
   +-------------+-------------+-------------+-------------+

 Bonica,Tappan,Gan      Draft-Expires May 2000                       6

7. 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.

   The extensions defined herein are in keeping with the spirit, if not
   the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC-
   1812 extends the final field of selected ICMP messages to include a
   greater portion of the original datagram. Unfortunately, it extends
   this field to a variable length without adding a length attribute.

   This memo binds the length of that final field to an arbitrarily
   large value (128 octets). Fixing the length of that field
   facilitates extension of the ICMP message. An additional object is
   provided through which octets 129 and beyond can be appended to the
   ICMP message.

   As few datagrams contain L3 or L4 header information beyond octet
   128, it is unlikely that the extensions described herein will
   disable any applications that rely upon RFC-1812 style ICMP
   messages.

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
   06.txt>, August, 1999

   [ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D.,
   Fedorkow, G., Li, T., Conta, A., _MPLS "MPLS Stack Encoding_, Encoding", Internet
   Draft, <draft-ietf-mpls-label-encapse-03.txt>, <draft-ietf-mpls-label-encapse-07.txt>, September 1998. 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. <draft-ietf-mpls-framework-05.txt>,
   September 1999.

   [MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
   Rosen, E., Swallow, G, _MPLS "MPLS using ATM VC Switching_, Switching", <draft-ietf-
   mpls-atm-01.txt>, November, 1998.

 Bonica,Tappan,Gan      Draft-Expires May 2000                       7
   [MPLSFRAME], Conta, A., Doolan, P., Malis, A., _Use "Use of Label
   Switching on Frame Relay Networks_, Networks", <draft-ietf-mpls-fr-03.txt>,
   November, 1998.

   [RFC-792], Postel, J., _Internet "Internet Control Message Protocol_, Protocol", RFC 792,
   ISI, September 1981.

   [RFC-1812], Baker, F., _Requirements "Requirements for IP Version 4 Routers_, Routers", RFC
   1812, June 1995.

   [RFC-2026], Bradner, S., _Internet "Internet Standards Process _ Revision 3_, 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.  Acknowledgments

   Thanks to Yakov Rekhter and Mike Heard for their contributions to
   this memo.

11. Author's Addresses

   Ronald P. Bonica
   MCI WorldCom
   2100 Reston Parkway
   Reston,
   22001 Loudoun County Pkwy
   Ashburn, Virginia, U.S.A. 20191 20147
   Phone: +1 703 715 7176 886 1681
   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

 Bonica,Tappan,Gan      Draft-Expires May 2000                       8

Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   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 implmentation 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

 Bonica,Tappan,Gan      Draft-Expires May 2000                       9