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.


. Abstract

   The current memo proposes extensions to ICMP that permit LSRs to
   append MPLS information to ICMP messages.

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


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

. 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



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

. 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


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


. 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



. 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