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