[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                           Z. Zhang
Internet-Draft                                    Juniper Networks, Inc.
Updates: 3032 (if approved)                                June 30, 2015
Intended status: Standards Track
Expires: January 1, 2016

                       MPLS ICMP for BIER Payload


   This document specifies an optional extension to generate ICMP
   messages for BIER packets transported over LSPs.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC2119.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 1, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Zhang                    Expires January 1, 2016                [Page 1]

Internet-Draft               mpls-icmp-bier                    June 2015

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Speficications  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   RFC3032 specifies that an LSR may generate ICMP messages if the
   payload is IPv4 or IPv6.  Normally the ICMP messages are label
   switched using the original label stack, and the egress LSR will then
   forward the the messages to the source of the packet.

   BIER [wijnands-bier-architecture] is a new multicast forwarding
   architecture and [kumarzheng-bier-ping] specifies ping/traceroute
   procedures for BIER.  BIER traceroute uses the same TTL-expiration
   principle of IPv4/IPv6 unicast traceroute.  A BFR (a router that
   supports BIER) may get a traceroute probe message whose TTL just
   expired at this hop and may send back a response, allowing a BFIR
   (ingress BFR) to gather the paths that a BIER packet traverses.

   It's possible that a BIER packet is transported over an LSP between
   two BFRs.  If Uniform Model for TTL is used for the LSP, when the
   ingress LER for the LSP put the BIER packet with a preceeding BIER
   label into the tunnel, the TTL from the BIER label is copied to the
   outgoing label for the LSP.  As a result, the TTL expiration may
   happen on an LSR on the LSP, who will silently drop the packet.  This
   TTL expiration could easily happen with traceroute, because the BFR
   that initiates the tracing will increase the TTL to be used one by
   one to discover the path.  The silent drop by an LSR is therefore

   If the LSR can generate an ICMP message for the TTL expiration, label
   switch it to the LER that advertised the inner most label just like
   in the IPv4/IPv6 case, that LER, which is is a BFR, will be able to
   process the TTL expiration for BIER traceroute purpose.

Zhang                    Expires January 1, 2016                [Page 2]

Internet-Draft               mpls-icmp-bier                    June 2015

   Note that in IPv4/IPv6 case, the generated ICMP message is addressed
   to the packet's source address and the message will be transparently
   routed back to the source of the packet by the LER that advertised
   the inner most label in the stack.  For BIER, the ICMP message is to
   be processed by the LER that advertised the inner most label.
   Therefore, the destination address of the ICMP message is set to
   local host address or ::1, depending on if the MPLS
   infrastructure is based on IPv4 or IPv6.

   In the following example diagram, there is an ingress BFR (BFIR), an
   egress BFR (BFER), and two transit BFRs (BFR1/BFR2) separated by two
   non-BFRs.  When BFIR sends a BIER packet, BFR1 will put the BIER
   packets into a tunnel between BFR1 and BFR2.  If Uniform model is
   used on BFR1, the tunneled packet could have TTL expiration on non-
   BFR1.  When that happens, non-BFR1 will generate an ICMP message
   addressed to local host address or ::1, and label switch to
   BFR2.  BFR2 will then process the ICMP message and may send
   appropriate response to the BFIR.

         BFIR --- BFR1  --- non-BFR1 --- non-BFR2 --- BFR2 --- BFER
                              ttl-expiration on non-BFR1;
                              generated ICMP message label switched to,
                              and processed by BFR2

                                 Figure 1

   In theory, it is possible that the outer LSP for which the LSR is
   having TTL expiration is the base LSP for a stacked LSP and the
   latter uses a differently versioned IP infrastructure, so the version
   of the ICMP message may be chosen incorrectly.  In reality, this is
   unlikely to happen because the label stack is to transport BIER
   packets between two BFRs that are in the same IGP domain.  Even if it
   does happen, it is likely that the LER is able to process both ICMP
   and ICMPv6 messages, and even if the LER is not able to process the
   incoming ICMP/ICMPv6 message it can discard the message silently -
   not much different from the LSR not generating the message the first

   It is expected that the BIER encapsulation header will start with a
   4-bit nibble with a unique value that suggests that it is a BIER

   This specification focuses on ICMP message generated for TTL
   expiration.  Other types of ICMP messages are out of the scope at
   this time.

Zhang                    Expires January 1, 2016                [Page 3]

Internet-Draft               mpls-icmp-bier                    June 2015

2.  Speficications

   When an LSR experiences a TTL expiration for a labeled packet and the
   first 4-bit nibble is X [TBD], the LSR MAY generate an ICMP message
   if the MPLS infrastructure is IPv4 based, or an ICMPv6 message if the
   MPLS infrastructure is IPv6 based.  The destination of the message is in case of IPv4 or ::1 in case of IPv6.  The source of the
   message is a routable address of the LSR.

   The LSR, if it supports BIER, MAY further check the BIER payload
   type.  If the "proto" field of the BIER header is "BIER OAM", the LSR
   SHOULD generate an ICMP or ICMPv6 message.

   To differentiate from ICMP/ICMPv6 messages generated for IPv4/IPv6
   playloads, the following message types are defined:

        ICMP messages:
          Type TBD1: TTL expired in tunnel
        ICMPV6 messages:
          Type TBD2: TTL expired in tunnel

   Alternatively, same message types but different code could be used to
   differentiate from IPv4/IPv6 payload triggered messages.  [This will
   be decided based on WG input]

   Except for the differences mentioned above in message type/code,
   destination address, and ICMP/ICMPv6 choice based on MPLS
   infrastructure type, the ICMP/ICMPv6 messages are constructed
   following existing procedures for IPv4/IPv6 payload.  The generated
   messages are label switched using the invoking packet's original
   label stack minus the inner most label.  The original inner most
   label for a BIER packet is a BIER label indicating that the payload
   type is BIER, so it must not be used for switching the generated
   ICMP/ICMPv6 messages, which are not BIER packets.  For a true BIER
   packet, the next inner most label is for the LSP terminating at the
   BFR that advertised the inner most label, so the original label stack
   minus the inner most label should get the generated ICMP/ICMPv6
   message to the right place for further processing.  For the example
   in Figure 1, when non-BRF1 experiences a TTL-expriation for a
   tunneled BIER packet, the label stack could be <tunnel label, BIER
   label>, where the tunnel label is advertised by non-BFR2 and the BIER
   label is advertised by BFR2.  With the BIER label removed, the
   resulting label stack <tunnel label> will get the generated ICMP
   message to BFR2 for further processing.

   The LER that originated the inner most label for the generated
   messages will receive the ICMP/ICMPv6 messages, which is addressed to
   the local host, and process the messages locally.

Zhang                    Expires January 1, 2016                [Page 4]

Internet-Draft               mpls-icmp-bier                    June 2015

   How the messages are processed is outside of the scope of this
   document, but in general the new ICMP message type/code causes the
   LER to examine the original packet header that is enclosed in the
   ICMP/ICMPv6 message and act accordingly, e.g., forward to BIER OAM
   module for further processing.  Because a non-BIER packet may be
   mistaken as a BIER packet (if the first nibble happens to be match),
   the receiving BFR MUST check the label stack included in the ICMP/
   ICMPv6 message to make sure that the inner most label is a BIER label
   that it advertised.

   It's possible that an IPv4 LER cannot process an incoming ICMPv6
   message, or vice versa.  It is also possible that an LER cannot
   recognize the new message type/code.  In these cases, it simply
   discard the message.

3.  IANA Considerations

   This document requests IANA to assigna a new message type in ICMP and
   ICMPv6 Parameters registries respectively.

4.  Security Considerations

   This document does not introduce new security risks, compared to
   generating ICMP messages for labeled IP packets.

5.  Acknowledgements

   The author thanks Eric Rosen, Ronald Bonica for their review,
   comments, and suggestions.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
              April 2007.

Zhang                    Expires January 1, 2016                [Page 5]

Internet-Draft               mpls-icmp-bier                    June 2015

   [RFC4950]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
              Extensions for Multiprotocol Label Switching", RFC 4950,
              August 2007.

6.2.  Informative References

              Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
              S. Aldrin, "Multicast using Bit Index Explicit
              Replication", draft-ietf-bier-architecture-00 (work in
              progress), April 2015.

              Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
              and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng-
              bier-ping-00 (work in progress), March 2015.

Author's Address

   Zhaohui Zhang
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA 01886

   EMail: zzhang@juniper.net

Zhang                    Expires January 1, 2016                [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/