[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                Sami Boutros (Ed.)
Internet Draft                                     Siva Sivabalan (Ed.)
Intended status: Standards Track                         George Swallow
Expires: September 2010                                      David Ward
                                                          Stewart Bryant
                                                     Cisco Systems, Inc.


                                                           July 6, 2009



          Connection verification for MPLS Transport Profile LSP
                  draft-boutros-mpls-tp-path-trace-00.txt


Status of this Memo

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

   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

   This Internet-Draft will expire on January 6, 2010.


Abstract

   This document specifies method for verifying the connection of an
   MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for
   management purpose. The proposed extension is based on MPLS
   Operation, Administration, and Maintenance (OAM). The goal is to
   verify that an MPLS-TP LSP is properly setup in both control and data


Boutros                Expires January 6, 2010                 [Page 1]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


   planes, as well as to record the identities of all the LSRs along the
   path of MPLS-TP LSP.

Table of Contents


   1. Introduction...................................................2
   2. Terminology....................................................4
   3. MPLS-TP Connection Verification Mechanism......................5
   4. MPLS-OAM Connection Verification Message.......................5
      4.1. In-band Message Identification............................5
      4.2. Out-of-band Message Identification........................6
      4.3. MPLS-TP CV Message Format.................................6
      4.4. MPLS-TP Connection Verification Record Route TLV.........10
      4.5. Network Management System................................10
   5. Operation.....................................................10
   6. Security Considerations.......................................12
   7. IANA Considerations...........................................12
   8. References....................................................13
      8.1. Normative References.....................................13
      8.2. Informative References...................................13
   Author's Addresses...............................................14
   Full Copyright Statement.........................................15
   Intellectual Property Statement..................................15

1. Introduction

      In traditional transport networks, circuits are provisioned on
   multiple switches. Service Providers (SP) need to verify that the
   circuits are provisioned correctly in both control and data plane for
   management purpose. MPLS-TP bidirectional LSPs emulating traditional
   transport circuits need to provide the same connection verification
   capability. In this document, an MPLS-TP LSP as defined in [5] is
   based on the MPLS-TE, pseudowire (PW) or Multisegment PW [8].

   An MPLS-OAM Connection Verification (CV) message originates at a
   Maintenance End Point (MEP) but can be directed to by any Maintenance
   Intermediate Point (MIP) along the path of MPLS-TP LSP as well as the
   other MEP. Therefore, the proposed mechanism addresses the
   verification of the full or partial path of an MPLS-TP LSP.

   An MPLS-OAM CV message is intercepted at any MIP based on MPLS TTL
   expiry, and at MEP simply because it is the end of the LSP (i.e.,
   regardless the value of the TTL).





Boutros                Expires January 6, 2010                 [Page 2]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


   In response to the MPLS-OAM CV request, each LSR along the path of
   the MPLS-TP LSP appends its ID using a newly defined TLV called
   Record Route TLV.

   A Record Route TLV appended by a given LSR contains:

     . The LSR address which is represented by the format defined in
        [6].

     . Local Labels allocated by the LSR for both directions of the
        MPLS-TP LSP.

   To describe the connection verification functionality, let us assume
   an MPLS-TP LSP between LSR-1 and LSR-5 passing through LSR-2, LSR-3,
   and LSR-4. Thus, LSR-1 and LSR-5 are MEPs whereas LSR-2, LSR-3, and
   LSR-4 are MIPs. The objective is to verify (both in control and data
   planes) the MPLS-TP LSP from LSR-1 to LSR-5 (end-to-end), and record
   all the IDs of the LSRs along the path. This could be accomplished
   using a conventional traceroute operation in which LSR-1 interrogates
   each LSR-2 through LSR-5 (using appropriate TTL value) in turn using
   a new message and response, and compiles the result. This approach
   requires 8 messages; a request and a response between LSR-1 and each
   of the other LSRs. On the other hand, the mechanism that we describe
   below can accomplish the goal with only 5 messages.

   It is possible that the path of an MPLS-TP LSP contains loop(s) due
   to misconfiguration. Such mistakes are possible with manual
   configuration. For example, assume that MPLS-TP LSP under discussion
   is misconfigured such LSR-4 connects to LSR-2 instead of LSR-5. This
   results in a loop. In this case, the MPLS-OAM CV packets self limit
   when the MTU is reached, and when it happens, it is good practice to
   silently drop those packets.

  If a MIP does not understand the MPLS-OAM CV message, it must
  silently drop the packet. To trap this condition as well as to trap
  the looping condition, an ingress MEP that initiates connection
  verification starts a timer when it sends an MPLS-OAM CV message. If
  the timer expires before the response arrives, the MEP assumes one of
  the following conditions:

     . the MPLS-TP LSP is incomplete.

     . an LSR (either MIP or MEP) does not understand the MPLS-OAM CV
        message.

     . there is a loop.



Boutros                Expires January 6, 2010                 [Page 3]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


   The ingress MEP then examines the MPLS-TP LSP by using the classic
   one-hop at a time, direct response traceroute.

  In case not all hops on the path of the MPLS-TP LSP are MIPs, an
  ingress MEP can send conventional trace route with incrementing TTL
  1, 2, 3, ...., to all MIPs and to the egress MEP along the path. Some
  of those requests will be sent to non MIP/MEP LSRs and will be
  dropped silently. When the MIPs and egress MEP receive the request,
  they will respond with an MPLS-OAM CV response message. The TTL value
  of the response SHOULD be large to ensure the response message
  reaches the ingress MEP without being intercepted at any MIP.
  Optionally, the TTL value of the response MAY be set to 1 so that
  each MIP can verify its ID included in the response message as the
  response travels towards the ingress MEP.

   The proposed mechanism is based on a set of new TLVs which can be
   transported using one of the following methods:


     1. Using in-band MPLS Connection Verification (CV) messages which
        are forwarded as MPLS packets (Non-IP routing and forwarding
        based).

     2. Using in-band LSP-Ping extensions defined in [2] where IP/UDP
        packets are used (IP-Based routing and forwarding). The LSP-
        Ping messages may be sent in-band using the  codepoint defined
        in [3].


   Method (1) and (2) are referred to as "in-band option" and "LSP-Ping
   option" respectively in the rest of the document.

   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 Error!
   Reference source not found.

2. Terminology

   ACH: Associated Channel Header

   CV: Connection Verification

   GAL: Generalized Alert Label



Boutros                Expires January 6, 2010                 [Page 4]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


   LSR: Label Switching Router

   MEP: Maintenance End Point

   MIP: Maintenance Intermediate Point

   MPLS-OAM: MPLS Operations, Administration and Maintenance

   MPLS-TP: MPLS Transport Profile

   MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit

   MS-PW: Mult-Segment PseudoWire

   NMS: Network Management System

   PW: PseudoWire

   RR: Record Route

   TLV: Type Length Value

   TTL: Time To Live

3. MPLS-TP Connection Verification Mechanism

   For the in-band option, the proposed mechanism uses a new code point
   in the Generic Associated Channel Header (G-ACH) described in [7].
   The LSP-Ping option will be in compliance to specifications [2] and
   [3].

   Moreover, the proposed mechanism requires Record Route TLV (defined
   in this document). Also, Authentication TLV defined in [4] is also
   required for this mechanism.

4. MPLS-OAM Connection Verification Message

4.1. In-band Message Identification

   In the in-band option, under MPLS label stack of the MPLS-TP LSP, the
   ACH with "MPLS-TP Connection Verification (CV)" code point indicates
   that the message is an MPLS-TP CV message.







Boutros                Expires January 6, 2010                 [Page 5]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009




   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|     Flags     |   0xHH MPLS-TP CV Code Point  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: ACH Indication of MPLS-TP Connection Verification

   The first nibble (0001b) indicates the ACH.  The version and the
   reserved values are both set to 0 as specified in [1].  MPLS-TP
   Connection Verification code point = 0xHH. [HH to be assigned by IANA
   from the PW Associated Channel Type registry.]

4.2. Out-of-band Message Identification

      [To be added]

4.3. MPLS-TP CV Message Format

   The format of an MPLS-TP CV Message is shown below.


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version       | Message Type  | Operation     | Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Return Code   | Cause Code    | Message Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender's Handle                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Message ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             TLV's                             |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 2: MPLS-TP CV Message Format


      Version


Boutros                Expires January 6, 2010                 [Page 6]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


         The Version Number is currently 1.

      Message Type
         The following two message types are defined:

         Message Type        Description
         ------------        -----------
            0x0              CV Request
            0x1              CV Reply


      Operation
         The following two operations are defined:

         Operation           Description
         ---------           -------------
            0x0              Only verify MPLS-TP LSP

            0x1              Verify MPLS-TP LSP and record route

            0x2              Verify MPLS-TP LSP, record route, and
                             verify LSR ID in the record route before
                             forwarding response


         First, all operation codes are meanigful only in the MPLS-TP CV
         request message, and this field currently ignored in the MPLS-
         TP CV response message.

         The operation code 0x0 is used to instruct a MIP or the
         receiver MEP to simply verify the MPLS-TP LSP associated with
         the MPLS-TP CV request message. In this case, after
         successfully processing the request message, an LSR should
         simply forward the message without appending Record Route TLV.

         The operation code 0x1 is used to instruct a MIP or the
         receiver MEP to not only verify the MPLS-TP but also append a
         Record Route TLV to the request message if the message is
         succesfully processed. Also, if the receiver needs to send a
         positive reponse back to the sender, it MUST include all the
         Record Route TLVs appended to the message by itself and all the
         upstream LSRs. Note that if a negative response is to be sent,
         Record Route TLVs are not appended to the response.



Boutros                Expires January 6, 2010                 [Page 7]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


         The operation code 0x2 is used to instruct a MIP receiving an
         MPLS-TP CV request message to verify the connection and append
         Record Route TLV. Additionally, it also instructs the LSR
         originating the response (MIP or MEP) to set the TTL value in
         the response such that the response will be intercepted by each
         upstream LSR. The intention is to let each upstream LSR to
         verify that the Record Route TLV that it appended to the
         request message exists in the response as well. Note that such
         verification is required only when positive response is sent.
         To facilitate such verification, the originator of the response
         as well as each LSR intercepting the response MUST set the TTL
         value to 1 in the response.

      Return code

         Value   Meaning
         -----   -------
           0     Success
           1     Failure


      Cause code

         Value   Meaning
         -----   -------
           0     No cause code
           1     Fail to find MPLS-TP LSP
           2     Malformed CV message received
           3     Received unknown TLV
           4     Authentication failed
           5     MPLS-TP LSP not setup in downstream direction
           6     MPLS-TP LSP not setup in upstream direction
           7     MPLS-TP LSP not setup in both directions
           8     LSR-ID is missing in the record route of positive
                 response

         In the case of cause code 3, the unknown TLVs can be optionally
         sent in the response message. Use cases of the above cause
         codes are explained in the operation section below.

         When MPLS-TP CV response travels back to the sender, a MIP
         intercepting the message could check if the Record Route TLV
         that it appended to the request exists in the response. As



Boutros                Expires January 6, 2010                 [Page 8]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


         such, the cause code 8 is meaningful only in the response
         message.

      Sender's Handle
         The Sender's Handle is filled in by the sender, and remains in
         tact as the CV request message travels. Also, this handle MUST
         be returned unchanged in all CV response messages. There are no
         semantics associated with this handle, although a sender may
         find this useful for matching up request with replies.

      Message Length
         The total length of any included TLVs.

      Message ID
         The Message ID is set by the sender of the MPLS-TP CV request
         message. It MUST be copied unchanged by any MEP or other MIP
         both in the CV request and response message. A sender SHOULD
         increment this value on each new message. A retransmitted
         message SHOULD leave the value unchanged.



      An MPLS-TP CV request message MUST contain a LSPI TLV to identify
      the MPLS-TP LSP being verified, Source Address TLV identifying the
      sender of the message, and Destination Address TLV identifying the
      target receipient of the message. Note that in the successful
      case, the MPLS-TP CV response message MUST be originated from the
      target recipient of the request, and the target receipient can be
      MIP or a MEP. However, in the case of negative response, the LSR
      that fails to process the message generates the response message.
      When sending a response, the Source Address TLV identifies the LSR
      originating the response and the Destination Address TLV
      identifies the intended receipient of the message (which is the
      source of the request message). Format of these TLVs are specified
      in [6]. Furthermore, an Authentication TLV defined in [4] can be
      optionally included in the request message as well.












Boutros                Expires January 6, 2010                 [Page 9]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


4.4. MPLS-TP Connection Verification Record Route TLV

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    type = TBD   |             Length = variable               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Upstream Label                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Downstream Label                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        LSR Address                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: MPLS-TP CV Record Route TLV format


   The Record Route TLV includes the LSR address sub-TLV defined in [6]
   as well as the upstream and downstream labels (allocated by the LSR
   for both directions of the LSP). The upstream label is the label
   allocated by the LSR for the direction of the connection verification
   request message. The label value of 0 means that a label is not
   allocated for the respective direction.

   Note that recording route is meaningful only if the connection
   verification operation is successful. As such, a receiver MUST
   examine any Record Route TLV only if the return code is 0 (success)
   in the connection verification response message.

4.5. Network Management System

   An operator should be able to provision any given LSR to send MPLS-
   OAM CV Request packets from a MEP and notify NMS when MPLS-OAM CV
   Response arrives.

   [More description is to added]

5. Operation

   Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <-->
   LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective
   direction. LSR-1 and LSR-5 are MEPs, and LSR-2 through LSR-4 are
   MIPs.

   The proposed mechanism operates as follows:


Boutros                Expires January 6, 2010                [Page 10]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


  1. LSR-1 sends an MPLS-TP CV Request message where the Source Address
     TLV, Destination Address TLV, and LSPI TLV represent LSR-1, LSR-5,
     and the LSP being verified respectively. An Authentication TLV may
     also be included.

  2. The MPLS-TP CV Request message is intercepted at LSR-2 (MIP)
     because of TTL expiry. LSR-2 then verifies the request and:

       1. if the MPLS-TP LSP cannot be located, it sends a response with
          return code 1 and cause code 1.

       2. if the message is malformed, it sends a response with return
          code 1 and cause code 2.

       3. if any of the TLV is not known, it sends a response with
          return code 1 and cause code 3. It may also include the
          unknown TLVs.

       4. if message authentication fails, it sends a response with
          return code 4 and cause code 4. This step is valid only if an
          Authentication TLV is present in the request.

       5. if the MPLS-TP LSP is not setup in downstream direction, it
          sends a response with return code 1 and cause code 5.

       6. if the MPLS-TP LSP is not setup in upstream direction, it
          sends a response with return code 1 and cause code 6.

       7. if the MPLS-TP LSP is not setup in both directions, it sends a
          response with return code 1 and cause code 7.

         Note that MPLS TTL value is set to 255 in the response message.
         In the response message, Source LSR address TLV is filled with
         the address of LSR-2.

         When LSR-1 receives the MPLS-TP CV Response, the Destination
         Address TLV indicates that it is the intended recipient of the
         message. Furthermore, it learns that connection verification
         for the MPLS-TP LSP in question failed at LSR-2 by examining
         the LSPI and Source Address TLVs respectively in the message.

  3. If LSR-2 is able to successfully process the MPLS-TP CV Request
     message, and if the MPLS-TP LSP is setup in both upstream and
     downstream directions, and if the destination address in CV request
     doesn't match LSR-2 address, it forwards the message to LSR-3 with
     TTL equals 1. LSR-2 appends its address as well as the upstream and



Boutros                Expires January 6, 2010                [Page 11]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


     downstream labels to the message if the operation code is 1 or 2.
     Otherwise, LSR-2 simply forwards the message to LSR-3.

  4. LSR-3 repeats the steps (2) or (3). In the absence of error, the
     messages progresses towards LSR-5 with each LSR adding its own ID
     and the local labels (for operation code 1 or 2).

  5. Upon getting the MPLS-TP CV message, LSR-5 verifies the request,
     and if an MPLS-TP LSP represented by LSPI TLV in the message is
     found, and if that MPLS-TP LSP is fully setup, LSR-5 checks the
     destination address in the CV request and if the destination
     address matches it's address LSR-5 sends an MPLS-TP CV response
     with return code 0 (success) back to the LSR-1. If the operation
     code in the request message is 1 or 2, LSR-5 appends all the Record
     Route TLVs received from upstream LSRs. Otherwise, the response
     does not include the Record Route TLVs received from the upstream
     LSRs. The TTL value in the response can set as follows:

       1. If the operation code in the request is 1, the TTL value is
          set to 255 so that the response message reaches LSR-1 without
          further interception at any other LSR.

       2. If the operation code in the MPLS-TP CV request message is 2,
          LSR-5 sends the response down the return path with TTL value
          equals 1 so that an LSR intercepting the message can verify
          its address and labels included in the response.

  6. In case LSR-4 receives the response message, it checks if its
     address and labels are included in the record route. If the check
     fails, it sends an MPLS-TP CV response with return code 1 (error)
     with cause code 8 back to LSR-1, and in this case the address of
     LSR-4 is included in the Source Address TLV of the response. If the
     check succeeds, LSR-4 simply forwards the message to LSR-3.

  7. When LSR-1 receives a response with a record route, it learns the
     address and the distance (in terms of hop count) of each LSR on the
     path of the MPLS-TP LSP.

6. Security Considerations

   The security considerations for the authentication TLV need further
   study.

7. IANA Considerations

   To be added.



Boutros                Expires January 6, 2010                [Page 12]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


8. References

8.1. Normative References

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

   [2]   K. Kompella, G. Swallow, "Detecting Multi-Protocol Label
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

   [3]   T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity
         Verification (VCCV): A Control Channel for Pseudowires ", RFC
         5085, December 2007.

8.2. Informative References

   [4]   S. Boutros, et. al., "Operating MPLS Transport Profile LSP in
         Loopback Mode ", draft-boutros-mpls-tp-loopback-02.txt, Work in
         Progress, March 2009.

   [5]   M. Bocci, et. al., "A Framework for MPLS in Transport
         Networks", draft-ietf-mpls-tp-framework-01.txt, Work in
         Progress, June 2009.

   [6]   S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
         bryant-mpls-tp-ach-tlv-02.txt, Work in Progress, May 2009.

   [7]   M. Bocci, et. al., "MPLS Generic Associated Channel", RFC 5589,
         June, 2009.

   [8]   Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
         Emulation Edge-to-Edge (PWE3)", RFC5254, October 2008.

















Boutros                Expires January 6, 2010                [Page 13]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


Author's Addresses

   Sami Boutros
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, California 95134
   USA
   Email: sboutros@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Canada
   Email: msiva@cisco.com

   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MASSACHUSETTS 01719
   United States
   Email: swallow@cisco.com

   David Ward
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, California 95134
   USA
   Email: wardd@cisco.com

   Stewart Bryant
   Cisco Systems, Inc.
   250, Longwater, Green Park,
   Reading RG2 6GB, UK
   UK
   Email: stbryant@cisco.com













Boutros                Expires January 6, 2010                [Page 14]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


Full Copyright Statement

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.



   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.



Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document.  Please
   address the information to the IETF at ietf-ipr@ietf.org.




Boutros                Expires January 6, 2010                [Page 15]


Internet-Draft draft-boutros-mpls-tp-path-trace-00.txt        July 2009


   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the UETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


























Boutros                Expires January 6, 2010                [Page 16]