Internet DRAFT - draft-yin-traceroute-ipmpls

draft-yin-traceroute-ipmpls







Internet Engineering Task Force                                   Y. Yin
Internet-Draft                                             S. Jiang, Ed.
Intended status: Informational                                     Z. Li
Expires: April 24, 2014                                          M. Chen
                                            Huawei Technologies Co., Ltd
                                                        October 21, 2013


        A Traceroute Framework in IP/MPLS Heterogeneous Networks
                     draft-yin-traceroute-ipmpls-00

Abstract

   This document introduces a traceroute framework that can obtain
   information of a real traffic flow path through heterogeneous IP/MPLS
   network environments.

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 April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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
   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.



Yin, et al.              Expires April 24, 2014                 [Page 1]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Procedures of the IP/MPLS Heterogeneous Traceroute Mechanism    2
     2.1.  New Components Needed . . . . . . . . . . . . . . . . . .   4
     2.2.  Form a New Echo-Request Message . . . . . . . . . . . . .   5
     2.3.  Process an Echo-Request Message . . . . . . . . . . . . .   5
       2.3.1.  Response requested information  . . . . . . . . . . .   5
       2.3.2.  Update Routing-Decide field . . . . . . . . . . . . .   6
       2.3.3.  Update Return-Path field  . . . . . . . . . . . . . .   6
       2.3.4.  Send a new Echo-Request message . . . . . . . . . . .   6
     2.4.  Process an Echo-Reply Message . . . . . . . . . . . . . .   6
     2.5.  Termination of the Traceroute Request . . . . . . . . . .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Change log [RFC Editor: Please remove]  . . . . . . . . . . .   7
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The current ISP networks may actually be constructed by IP/MPLS
   heterogeneous network technologies.  ISP services may be delivered
   across these IP/MPLS heterogeneous network environments.

   To locate the network fault quickly, IETF has defined the
   corresponding ping and trace functions for each network technology,
   independently.  However, none of these technologies are able to
   gather the trace information of all these heterogeneous network
   environments.  It is difficult to trace the complete end-to-end
   paths.  Another issue of these ping/trace functions is path
   replicability.  [I-D.yin-tsvwg-ipflow-pathtrace-ps] describes the
   issues and the requirements for a new IP/MPLS traffic flow path trace
   mechanism in details.

   In order to meet these requirements, this document introduces a new
   traceroute framework that traces the real traffic flow path while the
   real forwarding-relevant information are carried and updated in the
   path.  It can therefore obtain information of a real traffic flow
   path through IP/MPLS heterogeneous network environments.

   It is worthy of noticing that this mechanism requires support of all
   fowarding devices.  It is suitable to be used within a single
   administration domain.

2.  Procedures of the IP/MPLS Heterogeneous Traceroute Mechanism




Yin, et al.              Expires April 24, 2014                 [Page 2]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


   The new traceroute mechanism, introduced by this document, mainly
   targets the IP/MPLS heterogeneous networks.

   In order to describe the applicable scenarios and procedures, in this
   document, below network topology illustrates a traceroute example
   scenaio, in which the IP load balancing and traversing a MPLS network
   are demonstrated.

         |<-----------------Administration Domain--------------->|
         |                       |<-MPLS Domain->|               |
         |                     +---+   +---+   +---+             |
         |                 +---| C |---| M1|---| E |---+         |
   +---+ | +---+   +---+   |   +---+\ /+---+\ /+---+   |   +---+ | +---+
   | S |---| A |---| B |---+         X       X         +---| G |---| D |
   +---+ | +---+   +---+   |   +---+/ \+---+/ \+---+   |   +---+ | +---+
         |                 +---| D |---| M2|---| F |---+         |
         |                     +---+   +---+   +---+             |
         |                       |<-MPLS Domain->|               |
         |<-----------------Administration Domain--------------->|


   The real traffic is from the S(ource) node to the D(estination) node.
   The traceroute request is initialized at node A, and ideally
   terminated at node G. From the node B, the IP packet may be forwarded
   to node C or node D. Then it is MPLS domain, where the intermedia
   device M1 or M2 cannot be detected by current IP ping/trace
   mechanism.  This mechanism assume that all MPLS nodes have IP
   connectivities and can communicate with each other according to IP
   addresses.

   In the new traceroute mechanism, the traceroute requesting node
   passes three type of information, as illustrated in the below figure,
   to the next hop.  An example of traceroute request message:

          +-----------------------------------------------------+
          |      IP & UDP header for Echo-Request Message       |
          +-----------------------------------------------------+
          |Forwarding-Decide field contains Real IP/MPLS headers|
          +-----------------------------------------------------+
          |                      Options                        |
          +-----------------------------------------------------+


   The IP and UDP headers indicate the recipient - this is a traceroute
   request.  The Forwarding-Decide field contains real IP/MPLS headers,
   copied from a packet in a real traffic flow, or pseudo headers
   forming to represent a traffic flow.  It may include IP header, MPLS
   header and TCP/UDP header.  The IP/MPLS headers in the Forwarding-



Yin, et al.              Expires April 24, 2014                 [Page 3]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


   Decide field are maintained or modified in the exactly same way when
   a real traffic packet is processed in the forwarding procedure.
   Every on-path node decides the next hop according to the Forwarding-
   Decide field.  This would guarantee the traced route follows the same
   path of the real traffic packet, because the forwarding decide
   information is exactly same.  Options are mainly used to indicate the
   on-path nodes requested information and the return path.  The on-path
   nodes report the requested information of themselves to the
   traceroute requesting node directly.

2.1.  New Components Needed

   There are a few new components needed in order to fulfil the newly-
   introduced hop-by-hop traceroute mechanism.  They are listed below.

   Traceroute Port  A well-known UDP port that indicates the recipient
      devices that received UDP mesages are for traceroute purpose.

   An echo request message:  a new UDP message that is carrying the
      traceroute request.  It is processed, may be modified, then passed
      on hop by hop.

      *  Transaction ID, used to distinguish mutliple traceroute
         requests initiated by the same traceroute requesting node.

      *  Forwarding-Decide field, contains all information that may
         affect the path choice for a specific packet, including IP
         header, TCP/UDP header, MPLS header, and IP tunnel header.  The
         field contents are maintained or modified in the exactly same
         way when a real IP packet is processed in the forwarding
         procedure.

      *  Required-Information option, used to indicate the on-path nodes
         the information desired by the traceroute requesting node.

      *  Return-Path field, used to indicate the return path for the
         responsed Echo-Reply message.  It operates like a stack: the
         closed relay nodes first, then second close, till the original
         requesting node.

   An echo reply message:  a new UDP message that is used to return the
      requested information of intermedia node to the traceroute
      requesting node.

      *  Transaction ID, copied from the correspondent Echo-Request
         message.  It is used to distinguish mutliple traceroute
         requests initiated by the same traceroute requesting node.




Yin, et al.              Expires April 24, 2014                 [Page 4]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


      *  Information options, the information of the requested node.
         They are the response to the required information option.

      *  Return-Path field, copied from the correspondent Echo-Request
         message.  The MPLS or tunnel ingress nodes need these
         information to relay the Echo-Reply message to the traceroute
         requesting node.

   The detailed format or data structure is out of scope for this
   informational document.

2.2.  Form a New Echo-Request Message

   In the new traceroute mechanism, the traceroute request device (node
   A) forms an Echo-Request message, in which the Forwarding-Decide
   field contains a real IP header and TCP/UDP hearder that is copied
   from a packet in a real traffic flow, or a pseudo IP header and TCP/
   UDP hearder, towards node D. This Echo-Request message also indicates
   what information of these on-path devices are desired.  The
   traceroute request device also records itself in the Return-Path
   field.

   The Echo-Request message is carried by an IP packet, which the
   destination address is filled by the loopback address and source
   address is the requesting node itself.  IP TTL is set to value that
   indicate the maximum trace route hops.  It then sends the new IP
   packet towards the next hop according to the Forwarding-Decide field.

   This mechanism description in this section currently assumes that the
   traceroute requests start from IP.

2.3.  Process an Echo-Request Message

   Upon receiving the IP packet that contains an Echo-Request message,
   the recipiet node processes it to the new traceroute function,
   because of the loopback address and the newly defined Traceroute
   port.  There are four follow-up procedures on the recipient:
   responsing its own information, updating Fowarding-Decide field,
   updating Return-Path field, and sending a new Echo-Request message.

2.3.1.  Response requested information

   The new traceroute function returns the requested information of this
   node, according to Required-Information option in the Echo-Request
   message, back to the traceroute requesting node (or the closest relay
   node), by sending an Echo-Reply message.





Yin, et al.              Expires April 24, 2014                 [Page 5]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


   The IP address of the traceroute requesting node or the closest relay
   node, is obtained from the Return-Path field of the Echo-Request
   message.  Transaction ID is copied from the Echo-Request message.
   The Return-Path field from the Echo-Request message must be copied
   into the Echo-Reply message.

2.3.2.  Update Routing-Decide field

   The Forwarding-Decide field is maintained/modified in the exactly
   same way when the real traffic packet that the Forwarding-Decide
   field represents is processed, including add/remove new MPLS header,
   update MPLS label, add/remove IP tunnel header, NAT44 or NAT66
   translation or etc.

2.3.3.  Update Return-Path field

   The node first check whether the second close node in the Return-Path
   field is reachable or not.  If yes, it removes the closest node in
   the Return-Path field; if not, do nothing.  Note, if there is only
   one node in the Return-Path field, it must not be removed.

   The node then adds the IP address of itself into the Return-Path
   field, and the necessary information that this node must have in
   order to distinguish the previous node, such as Virtual Routing and
   Forwarding (VRF) information, etc.

2.3.4.  Send a new Echo-Request message

   This node then forms a new IP packet, in which the destination
   address is filled by the loopback address, source address is itself.
   It carries the Echo-Request message in the payload.  TTL in IP header
   is reduced by 1 every hop.

   According to the MPLS header, if there is, IP header and TCP/UDP
   hearder in the Forwarding-Decide field, the device decides the next
   hop, then sends the new IP packet towards the next hop.

2.4.  Process an Echo-Reply Message

   Upon receiving an Echo-Reply message that the destination IP address
   is itself, the recipient must decide whether the Echo-Reply is
   terminate here or needs to be relayed out, by checking whether it is
   the last node in the Return-Path field.








Yin, et al.              Expires April 24, 2014                 [Page 6]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


   If it is not the last node, it must be the first node.  It then
   obtains the necessary information for it to distinguish the next
   node.  It removes itself out of the stack of the Return-Path field.
   It then relays the Echo-Reply message to the next relay node or the
   original requesting node that it learns from the Return-Path field.

2.5.  Termination of the Traceroute Request

   Ideally, the traceroute request should be terminated at the edge of
   the administration domain if the traffic destination was out of
   domain, Node G in the example scenario.  The forwarding devices on
   the edge of the administration domain should be configured not to
   send traceroute messages out on the interfaces that connected to
   subscribers or devices out of the administration domain.

   However, the leak of traceroute request message should not bring much
   impact.  The subscriber node does not support this traceroute
   function would drop it siliently as unknown message.  The ingress
   devices of another administration domain or another ISP/transit
   network would filter this message.

3.  Security Considerations

   Without an authentication mechanim, this mechanism would be risk to
   expose network device information.  It should only be used either
   when combines with an authentication mechanim or in a closed single
   administration domain, in which the end user requests or request from
   outside of this administration domain should be filtered at the edge
   of the sdministration domain.

   The leak of traceroute request message does not create much security
   risk.  The information carried with in the message does not contain
   much sensitive information of the network.  The only potential risk
   information is exposing of the IP addresses of intermediate
   forwarding devices in the return parth option.

4.  IANA Considerations

   This memo includes no request to IANA.

5.  Acknowledgements

   This document was produced using the xml2rfc tool [RFC2629].

6.  Change log [RFC Editor: Please remove]

   draft-yin-hopbyhop-traceroute-00: original version. 2013-10-21.




Yin, et al.              Expires April 24, 2014                 [Page 7]

Internet-Draft   Traceroute in IP/MPLS Heterogeneous Env    October 2013


7.  Informative References

   [I-D.yin-tsvwg-ipflow-pathtrace-ps]
              Yin, Y., Jiang, S., and G. Yan, "IP Flow Path Trace
              Requirements", draft-yin-tsvwg-ipflow-pathtrace-ps-00
              (work in progress), July 2013.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

Authors' Addresses

   Yuanbin Yin
   Huawei Technologies Co., Ltd
   Q15, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: yinyuanbin@huawei.com


   Sheng Jiang (editor)
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com


   Zhenbin Li
   Huawei Technologies Co., Ltd
   Q15, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: lizhenbin@huawei.com


   Mach(Guoyi) Chen
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: mach.chen@huawei.com





Yin, et al.              Expires April 24, 2014                 [Page 8]