Internet DRAFT - draft-ali-ccamp-gmpls-lsp-ping-traceroute

draft-ali-ccamp-gmpls-lsp-ping-traceroute



CCAMP Working Group                                         Zafar Ali 
Internet Draft                                         Roberto Cassata 
Intended status: Standards Track                   Cisco Systems, Inc. 
                                                        Marco Anisetti 
                                                      Valerio Bellandi 
                                                       Ernesto Damiani 
                                                       Francesco Diana 
                                                      Umberto Raimondi 
                                                   University of Milan 
                                 T. Otani(KDDI R&D Laboratories, Inc.) 

   Expires: August 2008                              February 25, 2008                                                                      
                                      
     Ping and Traceroute with Evidence Collection in Photonic Networks 
             draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt
                                      
Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   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 August 25, 2008. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 

Abstract 

 
 
 
Z. Ali, et Al.         Expires August 2008                [Page 1] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   [RFC4379] describes procedures for ping and tracerouting for LSPs 
   with PSC (packet switch capable) transit switching capability. An 
   important implication of using transparent (non-PSC) nodes in GMPLS 
   network is that LSP Ping solution described in [RFC4379] are not 
   applicable to LSP with non-PSC switching capability. Another 
   important difference between PSC and non-PSC switching technologies 
   is the data and control plan separation in the latter case. An 
   implication of the separation of data and control planes in GMPLS 
   networks is that LSP traceroute procedures described in [RFC4379] are 
   not directly applicable to GMPLS networks with separation of data and 
   control planes.  

   The scope of this draft is cases where data plane does not provide 
   the OAM functions addressed by this draft. This document is assumed 
   that OAM mechanisms provided by the underlying data plan technology 
   MUST be used, whenever possible. E.g., G.709 addresses the problem of 
   trace routing in DWDM network. However, G.709 OAM mechanisms are only 
   applicable to OEO (Optical-Electrical-Optical) capable node. This 
   document fills in such gaps; in particular it addresses GMPLS OAM 
   functionality in optical networks with wavelength routers, ROADMs 
   nodes, etc. with no OEO conversion capability. For this purpose, the 
   draft relies on control plan mechanism to provide required OAM 
   functions. Specifically the proposed solutions are based on Link 
   Management Protocol (LMP) [RFC4204] and RSVP-TE [RFC3209], [RFC3473] 
   and do not require any extension to the data plan.  

Conventions used in this document 

   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 

   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. 

Table of Contents 

    
   1. Introduction................................................3 
   2. Tracerouting with Evidence Collection........................4 
      2.1. Optical Path Quality Evaluation.........................5 
      2.2. Optical Evidence Classification and LSP Locking..........6 
      2.3. Optical Evidence Collection.............................7 
      2.4. Evidence Collection Request TLV.........................8 
      2.5. Evidence recording TLV..................................8 
      2.6. Administrative Status Object extension..................9 

 
 
Z. Ali, et al          Expires August 2008                [Page 2] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

      2.7. Signaling Procedure for tracerouting with evidence collection
       ...........................................................10 
         2.7.1. Tracerouting with non-blocking evidence collection.10 
         2.7.2. Tracerouting with blocking evidence collection and all 
         nodes ready for evidence collection......................11 
         2.7.3. Tracerouting with blocking evidence collection with some 
         node(s) blocked for evidence collection..................12 
   3. LSP Ping for GMPLS LSPs.....................................13 
      3.1. LSP Verification Procedure.............................15 
   4. Security Considerations.....................................15 
   5. Acknowledgments............................................16 
   6. References.................................................16 
      6.1. Normative References...................................16 
      6.2. Informative References.................................16 
   Author's Addresses............................................17 
   Intellectual Property Statement................................18 
   Disclaimer of Validity........................................18 
    
   1. Introduction 

   When a GMPLS LSP fails to deliver user traffic, the failure cannot 
   always be detected by the GMPLS control plane.  There is a need to 
   provide a tool that would enable users to detect such traffic "black 
   holes" or misrouting within a reasonable period of time, and a 
   mechanism to isolate faults [GMPLS-OAM-REQ]. Similarly, ability to 
   traceroute a GMPLS LSPs in networks where data and control planes are 
   separated is a requirement [GMPLS-OAM-REQ]. This draft provides 
   solution to these requirements.  

   The scope of this draft is cases where data plane does not provide 
   the OAM functions addressed by this draft. This document is assumed 
   that OAM mechanisms provided by the underlying data plan technology 
   MUST be used, whenever possible. E.g., G.709 addresses the problem of 
   trace routing in DWDM network. However, G.709 OAM mechanisms are only 
   applicable to OEO (Optical-Electrical-Optical) capable node. This 
   document fills in such gaps; in particular it addresses GMPLS OAM 
   functionality in optical networks with wavelength routers, ROADMs 
   nodes, etc. with no OEO conversion capability. For this purpose, the 
   draft relies on control plan mechanism to provide required OAM 
   functions.  

   [RFC4379] describes control plan procedures for LSP Ping for LSPs 
   with PSC (packet switch capable) endpoint and transit switching 
   capability devices. LSP Ping solutions described in [RFC4379], 
   however, are not applicable to LSPs crossing or terminating non-PSC 
   switching capable devices. This is because the solution described in 
   RFC4379 requires all transit and end point nodes along the LSP path 
 
 
Z. Ali, et al          Expires August 2008                [Page 3] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   to be able to intercept the MPLS OAM (Operation and Maintenance) 
   packets and identify the Target FEC Stack being tested. Such 
   capability is not available at nodes that are non-PSC-capable. 
   Moreover, LSP ping mechanisms described in [RFC4379] can be 
   inadequate even when the end points of the GMPLS LSP are PSC-capable. 
   This is because the GMPLS LSP appears as a single hop for procedures 
   described in [RFC4379]. In such cases, mechanisms in [RFC4379] are 
   able to detect data plan failure in the GMPLS LSP but are still not 
   able to isolate failures in underlying switching layers. 

   The Link Management Protocol (LMP) [RFC4204] fault isolation 
   mechanism can be used to detect and isolate failures along a GMPLS 
   LSP, but it requires the GMPLS LSP to be carrying traffic. Inability 
   to use LSP fault isolation is a considerable limitation for operators 
   wanting to check the health of an LSP before carrying traffic over 
   it. This draft addresses this limitation by extending the LMP link 
   verification procedure to check connectivity of a GMPLS LSP and 
   extending the RSVP-TE to detect the faulty point.  

   For successful fault detection on a light-path, the fault isolation 
   mechanism must be aware of all physical evidence (consisting of 
   optical measurements such as signal power, OSNR, OCM (Optical Channel 
   Monitor), etc.) that have effect on the light-path. The proposed 
   technique is also suitable for optical networks that suffer of 
   physical dysfunction due the non-ideal optical transmission medium 
   and/or to critical situations (e.g., a fiber cut). In this scenario 
   even if every node along the path is connected, the reachability of 
   the end node with an acceptable signal quality is not guaranteed.  

   Such evidence can consist of real optical measurements or estimates 
   computed via a prediction model.  The former may require mutually 
   exclusive access to hardware to avoid interference; therefore, 
   evidence can also be classified as blocking or non-blocking. This 
   draft address both type of evidence collections. Furthermore, in this 
   draft evidence collection is performed during the phase of trace 
   routing.  

   2. Tracerouting with Evidence Collection 

   Traceroute is often used for network troubleshooting. Specifically, 
   it is used identify the LSP taken to reach a particular destination 
   viewing the all transit nodes on the network; for that reasons it is 
   used also to detect faulty point inside a route. 

   The LSP traceroute procedures described in [RFC4379] are not directly 
   applicable to GMPLS networks with separation of data and control 
   planes. To overcome this issue tracerouting using RSVP RRO object 
 
 
Z. Ali, et al          Expires August 2008                [Page 4] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   [RFC4561] can be implemented. This strategy is only a control plain 
   view. However, maintain a coherence with data channel in the sense of 
   traversed nodes it detects a faulty point in the control channel that 
   is largely different than finding the faulty point in the data 
   channel. 

   This draft proposes a technique to address the deficiency of the use 
   of RRO for tracerouting a GMPLS LSP. The proposed is control plan 
   based but is able perform a traceroute with fault isolation coherent 
   with data channel. The proposed method is able to perform 
   tracerouting with evidence collection. It is based on the idea that 
   for successful fault detection on an optical path, the fault 
   isolation mechanism must be aware of all physical evidence 
   (consisting of optical measurements such as signal power, OSNR, 
   Optical Channel Monitor, etc.) that have effect on the light-path. 
   Therefore measuring or estimating some physical evidences along an 
   optical path address the actual control channel deficiency in finding 
   the data channel coherence traceroute. 

    

   2.1. Optical Path Quality Evaluation 

   The quality of an optical path is done by collecting the physical 
   evidences along an LSP and evaluating them (e.g. for faulty point 
   detection). As already mention this feature integrates the 
   tracerouting in such a way that the control channel becoming aware 
   and coherent with data channel. The holistic analysis proposed 
   produce also a quality of path awareness. 

   In this draft we extend the LSP_ATTRIBUTES to perform the evidence 
   collection hop by hop. 

   Other important concept defined by this evidences collection process 
   is that certain evidences (blocking evidence) require a mutually 
   exclusive access. Therefore the entire LSP needs to be locked until 
   the evidence collection process is performed. This implies that if 
   other evidence collection process tries to retrieve evidences on the 
   same node-resource already under Administrative Evidences Locking 
   status, it MUST be aborted. The draft uses RSVP Admin status object 
   to define LSP Administrative Evidences Locking status and to make 
   sure that all nodes are ready to collect the blocking evidence.  

   In the following we first define Optical Evidence classification, and 
   extension to LSP ATTRIBUTE and RSVP Admin status objects needed to 
   perform above mentioned functionalities. The later sections details 

 
 
Z. Ali, et al          Expires August 2008                [Page 5] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   signaling procedures with examples on how these objects are used for 
   tracerouting with evidence collection.  

   2.2. Optical Evidence Classification and LSP Locking 

   Physical evidences (consisting of optical measurements such as signal 
   power, OSNR, Optical Channel Monitor, etc.) that have effect on the 
   light-path are classified as: 

   o  Blocking evidence. In general blocking evidence is a physical 
   measurement that may require a mutually exclusive access to hardware 
   resources while performing the measurement. 

   o  Non blocking evidence. Every physical values that can be probed in 
   parallel with different RSVP-TE. 

   Every optical Node can be in three states related to a certain 
   reserved resource: unlock, lock-required or lock. In fact blocking 
   evidence MUST generate a lock on each reserved resource required for 
   evidence reading. In general this is due to the hardware limitation 
   of optical nodes.   

   In case of blocking evidence the LSP status needs to be set to 
   "Locked". To perform this status changing we use the Admin object  
   [RFC3471] with B bit (Blocked bit) and C bit (block Confirm) 
   extension. In our LSP locking strategy also the R bit (Reflect bit) 
   MUST be set since the egress node MUST return the Admin object in the 
   Resv Message for locking confirmation or unlocking. Since we need to 
   block an entire LSP, one node unable to measure the required blocking 
   evidence MUST generate a lock failure (unset the C bit in the Path 
   Admin Object). Therefore the evidence locking is considered 
   mandatory. 

   The general locking procedure is defined as follow: 

   o  Every transit node that receives the Admin status object in the 
   Path message with B, C and R bit set needs to check if the actual 
   status is unlock. 

   o  In the case of unlock status, the node switches to lock-required 
   state related to the required blocking evidence. 

   o  In the case of lock or lock-required statuses, the node forwards 
   the Admin object message without the C bit set. This implies a lock 
   failure. 


 
 
Z. Ali, et al          Expires August 2008                [Page 6] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   o  The Resv message performs the locking for the entire LSP in case 
   of C and B bit set and unlocking in case of unset C bit. 

   o  Every transit node that receives the Resv message with B and C bit 
   set changes its status to lock.  

   This strategy prevents race conditions.  

   2.3. Optical Evidence Collection  

   Path quality evaluation is based on holistic analysis of the evidence 
   collected inside an LSP. To determinate which evidence needs to be 
   collected we adopt a LSP Attribute TLV sub-object. 

   The evidence collection is performed as follows:  

   o  Source node sends a Path message with LSP Attribute object aimed 
   to inform the transit nodes about the imminent evidence collection 
   This downstream Path message also contains TLV sub-object with 
   required evidence.  

   o  Every transit node, when receives the message with LSP Attribute 
   object, assembles the collected evidence (specified in TLV) inside a 
   sub-TLV. The way an optical node gets knowledge of the evidence using 
   information locally available at the node (e.g. via discovery of 
   internal amplifiers, photodiode etc.) is out of the scope of this 
   document.  

   o  Evidence collection will be executed by the returning Resv message 
   that collects hop-by-hop evidence objects upstream by inserting the 
   sub-TLV inside the attached TLV. After successful forwarding of Resv 
   message the status of transit nodes MUST be switched to unlock for 
   preventing deadlock. 

   In case of blocking evidence the LSP lock MUST be performed before 
   evidence collection. 

   In case of non-blocking evidence the unavailability of certain 
   evidence in an intermediate node MUST NOT cause the request of 
   failure (PathErr message) since the holistic evidence evaluation 
   SHOULD be able to deal with missing non-blocking evidence. 

   When one transit node not in locking state receives a request for 
   blocking evidence, an evidence collection failure (PathErr) MUST be 
   triggered.  

 
 
 
Z. Ali, et al          Expires August 2008                [Page 7] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   2.4. Evidence Collection Request TLV 

   NOTE: INFORMATION IN THIS SECTION NEED SOME CAREFUL REVISION AGAINST
   EXPECTED USAGE IN [RFC4420].  

   The proposed encoding scheme for optical evidence measurements 
   defines a TLV associated to a particular evidence type. A TLV sub-
   object is encoded in an LSP_REQUIRED_ATTRIBUTES Object [RFC4420]. The 
   TLV sub-object encoding is: 

    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              |           Length              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     E-Type    |                    Reserve                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Type: Collected evidence type(TBA). Can be blocking or non blocking 
   type.    

   Length: length of the TLV object in bytes without the 4 byte header. 

   E-type (Evidence Type, 8 bits): Evidence identifier, for instance: 0 
   as Signal power, 1 as OSNR, 2 as Pilot Tone (as blocking evidence). 

   This TLV defines which type of evidence needs to be collected and 
   specifies the evidence (signal power, OSNR, Pilot Tone, alarm etc.) 
   in the Path message. 

 
   2.5. Evidence recording TLV 

   NOTE: INFORMATION IN THIS SECTION NEED SOME CAREFUL REVISION AGAINST
   EXPECTED USAGE IN [RFC4420].  

   For provisioned LSP, a set of evidence has to be collected through 
   the Resv message to allow the optical quality evaluation at the 
   ingress node. Each item of optical evidence is collected separately. 
   Every transit node, in the Path message, finds the Evidence 
   collection requested TLV and stores in the Evidence recording TLV 
   (encoded in an LSP_ATTRIBUTES Object) its own measured or estimated 
   value. Furthermore it sets the Measure Method inside the this TLV 
   according to the kind of measured media (single lambda measurement or 
   aggregate measurement). 
   This evidence collection improves the feasibility evaluation where 
   network elements support at least only a subset of evidence. 
 
   The following TLV encode the evidence's values of the LSP associated 
   to the evidence type defined in the Evidence Collection Request TLV. 
 
Z. Ali, et al          Expires August 2008                [Page 8] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

    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                       |         Length                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  IPv4/IPv6 Address/unnumbered                                 | 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  Evidence Value                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |Measure Method |                 Reserved                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
     
   Type: Evidence type(TBA).  
    
   Length: length of the TLV value in bytes. 
    
   IPv4/IPv6 Address: The address of the Node that measures the 
   evidence. 
    
   Evidence Value: Estimated or measured evidence value. For instance 
   the Signal Optical Power as 32-bit IEEE floating point number. 
    
   Measure(ment) method: Aggregate measurement (0) or single lambda 
   measurement (1). 
    
    
   2.6. Administrative Status Object extension 

   We propose and extension to Administrative status object by adding 
   two bits for locking purpose. 
    
   Therefore the format of the extended Admin_Status Object is: 
    
    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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |            Length             | Class-Num(196)|   C-Type (1)  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |R|         Reserved                                  |C|B|T|A|D| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Reflect (R): 1 bit 
   When set, indicates that the edge node SHOULD reflect the object/TLV 
   back in the appropriate message.  This bit MUST NOT be set in state 
   change request, i.e., Notify, messages. 
    

 
 
Z. Ali, et al          Expires August 2008                [Page 9] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   Reserved: 25 bits. This field is reserved.  It MUST be set to zero on 
   transmission and MUST be ignored on receipt.  These bits SHOULD be 
   passed through unmodified by transit nodes. 
    
   Testing (T): 1 bit. When set, indicates that the local actions 
   related to the "testing" mode should be taken. 
    
   Administratively down (A): 1 bit. When set, indicates that the local 
   actions related to the "administratively down" state should be taken. 
    
   Deletion in progress (D): 1 bit. When set, indicates that that the 
   local actions related to LSP teardown should be taken.  Edge nodes 
   may use this flag to control connection teardown. 
    
   Blocking node (B): 1 bit. When set, indicates that locking procedure 
   is ongoing. 
    
   Confirm blocking (C): 1 bit. When set, indicates that an the locking 
   procedure is successfully ongoing. 
 

   2.7. Signaling Procedure for tracerouting with evidence collection 

   In this section we describe signaling procedures for tracerouting 
   with evidence collection using examples. Consider a GMPLS LSP that 
   has OXC1 as Ingress Node, OXC4 as Egress node with OXC2 and OXC3 in 
   transit, as shown below.  

  
          +------+       +------+       +------+       +------+ 
          |      | ----- |      | ===== |      | ----- |      | 
          | OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 | 
          |      | ----- |      | ----- |      | ===== |      | 
          +------+       +------+       +------+       +------+ 
    

   In the following we consider three scenarios of evidence collection 
   and describe signaling procedures associated with the evidence 
   collection and how above mentioned extensions to LSP Attribute and 
   admin status objects are used for this purpose.  

    2.7.1. Tracerouting with non-blocking evidence collection 

   The quality evaluation of an optical path is done after LSP 
   provisioning and in case of non-blocking evidences is implemented by 
   the following procedure: 
 
 
Z. Ali, et al          Expires August 2008               [Page 10] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   o  OXC1 node sends a Path message with Evidence Collection Request 
   TLV aimed to inform the transit nodes about the imminent evidence 
   collection and about the type of evidence that needs to be collected 
   (e.g., Signal power).  

   o  The transit nodes that do not support LSP_REQUIRED ATTRIBUTE 
   object or do not support evidence request TLV will be addressed in a 
   later version of the document.   

   o  Every transit node (OXC2,OXC3), when receives the Path message 
   with Evidence Collection Request TLV, starting the internal evidence 
   reading procedure and waits for the correspondent Resv message to 
   forward the related Evidence recording TLV in the upstreaming flow to 
   the ingress node OXC1. If for some reason the evidence is not 
   available, since it is non blocking evidence, the node simply do not 
   include the evidence measure in its own Evidence recording TLV. The 
   holistic analysis can be performed also with a subset of the non 
   blocking evidences.  

   o  Egress node OXC4 sends Resv message with Evidence Collection 
   Request TLV containing optical evidence TLV upstream to the ingress 
   node OXC1 and puts its own evidence value in this Evidence recording 
   TLV. 

   o  Every transit node (OXC3,OXC2) inserts its own Evidences recording 
   TLV inside Resv message in such way that ingress node collects all 
   required evidences hop by hop using the upsteaming flow.  

   o  OXC1 node when receives the Resv message extract the Evidences 
   recording TLV to perform holistic path quality analysis.  

   Summarizing the Evidence collection will be executed by the returning 
   Resv message that collects hop-by-hop evidence objects upstream. 

2.7.2. Tracerouting with blocking evidence collection and all nodes 
   ready for evidence collection 

   In this scenario the locking strategy needs to be performed first to 
   be sure that no one node in the LSP is already locked in another 
   blocking evidences collection. Summarizing we need to be sure that 
   all nodes along the path are ready to collect the evidence. This 
   phase uses Admin status object in the path and Resv message to  

   The locking procedure is defined as follow: 

   o  OXC1 switches to lock-required state and sends a Path message with 
   Admin status object with B, C and R bit set. B bit is used for 
 
 
Z. Ali, et al          Expires August 2008               [Page 11] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   locking requirement. C bit is used for locking confirmation if set 
   and for unlock if unset.  

   o  Every transit node (OXC2, OXC3) that receives the Admin status 
   object in the Path message with B, C and R bit set switches to lock-
   required state related to the required blocking evidence. 

   o  Egress node OXC4 switches to lock state forward the Admin status 
   object in the Resv message resetting the R bit. 

   o  Every transit node (OXC3,OXC2) that receives the Resv message with 
   B and C bit set changes its status to lock.  

   o  Ingress node OXC1 when receive the Resv message with Admin status 
   object with B and C bit set switches to lock states. 

   At the end of this procedure the entire LSP is in lock state and is 
   ready for blocking evidence collection.  

   At this stage the Evidence collection can be performed as described 
   in the Section 2.7.1 except that every transit nodes need to change 
   its own status to unlock to prevent deadlock as described in the 
   Evidence collection Section (2.3). 

   The locking strategy is performed before evidence collection to 
   maintain a better compatibility with the future available blocking 
   evidences kind that would require further action to be taken before 
   starting the collection. 

 

2.7.3.  Tracerouting with blocking evidence collection with some node(s) 
blocked for evidence collection. 

   In this scenario the locking procedure fails since some nodes (e.g 
   OXC3 is in locking or lock-required state over other LSP) 

   o  OXC1 switches to lock-required state and sends a Path message with 
   Admin status object with B, C and R bit set. B bit is used for 
   locking requirement. C bit is used for locking confirmation if set 
   and for unlock if unset.  

   o  OXC2 receives the Admin status object in the Path message with B, 
   C and R bit set switches to lock-required state related to the 
   required blocking evidence. 


 
 
Z. Ali, et al          Expires August 2008               [Page 12] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   o  OXC3 node when receives the Admin status object since it is 
   already lock or lock-required over other LSP with the same resources, 
   unset the C bit. Therefore the locking procedure will fails. 

   o  Egress node OXC4 since receives the Admin object without C bit set 
   switches to unlock state and forwards the received Admin status 
   object in the Resv message resetting the R bit. 

   o  Other transit nodes (OXC3, OXC2) when receive the Admin object in 
   the Resv message with B bit set but with C bit unset, switch to 
   unlock state. 

   o  The ingress node OXC1 when receives Resv message with Admin object 
   containing B bit set and C bit unset switches to unlock. 

   At this stage the Locking strategy is failed since the ingress node 
   does not receive the confirmation of successful locking (C bit set). 

    

   3. LSP Ping for GMPLS LSPs  

   Tracerouting with evidence collection described in the last section 
   is an expensive signaling operation. Most of the time service 
   provider's requirement is to test connectivity verification, and to 
   perform tracerouting with evidence collection when detailed 
   diagnostic of LSP is needed.  

   If the end-points of the LSP are PSC capable, LSP ping procedure in 
   [RFC4379] can be used. However, if LSP end-points are non-PSC 
   capable, LMP procedure described in this section can be used to 
   provide LSP ping functionality for GMPLS LSPs. For this purpose, this 
   draft proposes an extended LMP model as shown below.  

  
          +------+       +------+       +------+       +------+ 
          |      | ----- |      | ===== |      | ----- |      | 
          | OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 | 
          |      | ----- |      | ----- |      | ===== |      | 
          +------+       +------+       +------+       +------+ 
            ^ ^            ^  ^           ^ ^             ^  ^ 
            | |            |  |           | |             |  | 
            | +----LMP1----+  +----LMP2---+ +-----LMP3----+  | 
            |                                                | 
            +----------------------LMP4----------------------+ 
 
 
Z. Ali, et al          Expires August 2008               [Page 13] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

                       Figure 1 Extended LMP Model. 

   In this model, non-adjacent nodes may establish and maintain LMP 
   sessions that can be used to check the status of a GMPLS LSP. Also, 
   the nodes continue to maintain hop-by-hop LMP sessions to build 
   traffic-engineering (TE) links for GMPLS signaling and routing, as 
   described in [RFC4204]. For example in Figure 1, OXC1-OXC2, OXC2-
   OXC3, and OXC3-OXC4 LMP sessions are used to build traffic-
   engineering (TE) links for GMPLS signaling and routing, while the LMP 
   session OXC1-OXC4 (LMP4) is used to monitor the health of GMPLS 
   LSP(s) with OXC1 and OXC4 as end-points. Note that the LMP session 
   between LSP end-point nodes is only used for OAM purposes. Existing 
   signaling mechanisms are used to discover remote link property.  

   Once an LMP session between LSP end-point nodes comes up, Link 
   connectivity verification can be used to perform LSP connectivity 
   verification.  This is done by sending Test messages over the GMPLS 
   LSP and TestStatus messages back over the control channel. For this 
   purpose, LMP connectivity verification procedure as described in 
   [RFC4204] is used. Note that in this model the verification of a 
   GMPLS LSP is not confined to LSPs having endpoint nodes that are PSC-
   capable, but effectively to LSPs of endpoint nodes that reside at any 
   of the GMPLS switching layers.  

   In what follows, we outline how existing LMP and MPLS OAM procedures 
   needs to be applied to provide tracerouting functionality in 
   scenarios outlined above. Again recall the scope of this draft is 
   cases where data plane does not provide the OAM functions addressed 
   by this draft. 

   The control channel management for LSP ingress-node-to-egress-node is 
   the same as described in [RFC4204]. To distinguish between a LSP 
   ingress-node-to-egress-node LMP session and a peer node-to-peer node 
   LMP session, a new LMP_TARGET_HELLO_CONFIG object is defined (C-Type 
   = TBD).  The format of the CONFIG object is as follows: 

    Class = TBD 
  
    o     C-Type = TBD, LMP_TARGET_HELLO_CONFIG 
  
     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |T|                        (Reserved)                           | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

 
 
Z. Ali, et al          Expires August 2008               [Page 14] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

  
    The Reserved field should be sent as zero and ignored on receipt. 
  
    T:  1 bit 
  
    This bit indicates support for the LMP-LSP-Verification extensions 
 defined in this document. 
  
   To establish an ingress-node-to-egress-node LMP session, sender node 
   uses the control plane's IP address of the LSP destination node, 
   while sending the LMP_TARGET_HELLO_CONFIG message. The ConfigAck and 
   ConfigNack messages MUST be sent to the source IP address found in 
   the IP header of the received Config message. 

   3.1. LSP Verification Procedure 

   Link verification procedure described in [RFC4204] has been adapted 
   for LSP verification. Specifically, once a control channel has been 
   established between the ingress and egress nodes of an LSP, LSP 
   connectivity can be verified by exchanging Test messages between 
   nodes along the GMPLS LSP's path. Since the LSP's health can be 
   tested along the forwarding transmit path, both endpoints nodes can 
   (independently and simultaneously) initiate the exchange of Test 
   messages in each direction to test for the health of bidirectional 
   LSPs. 

   To initiate the link verification procedure, the Ingress (Egress) 
   node MUST send a BeginVerify message over a control channel with the 
   IP address of the destination (source) node of the LSP.  To limit the 
   scope of LSP Verification to a particular LSP, the local Lsp_Id 
   assigned by the local node is used. This Lsp_Id is learned by the 
   remote node during signaling and MUST be non-zero. If this field is 
   zero, the verification can span multiple TE LSPs between the set of 
   Ingress/Egress nodes involved in the verification process. The rest 
   of the details for LSP verification are the same as described for 
   link verification in [RFC4204].  

    

   4. Security Considerations 

   Security considerations and requirements form [RFC4204] and [RFC4379] 
   apply equally to this document. Furthermore, there are some 
   additional security considerations that may be induced by extended 


 
 
Z. Ali, et al          Expires August 2008               [Page 15] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   LMP model and RSVP-TE proposed by this draft. These security 
   considerations will be added in a later version of the draft.     

   5. Acknowledgments 

   Authors would like to thank Alberto Tanzi, Ferdinando Malgrati, 
   Domenico La Fauci, Enzo Luca Passerini, Gabriele Galimberti for their 
   valuable inputs. 

6.  IANA Considerations

   TBA.

   7. References 

   7.1. Normative References 

   [RFC4204] Lang, J., et al., "Link Management Protocol (LMP)", RFC 
   4204, October 2003. 

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

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 
   and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 
   3209 ,December 2001. 

   [RFC3471] Berger, L., et al., "Generalized Multi-Protocol Label 
   Switching (GMPLS) Signaling Functional Description", RFC 3471, 
   January 2003. 

   [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label 
   Switching (GMPLS) Signaling", RFC 3473, RFC 3473, January 2003. 

   [RFC4561] Vasseur, J.-P.,Ali, Z., Sivabalan, S., "Definition of a 
   Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, June 2006. 

   [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. 
   Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching 
   (MPLS) Label Switched Path (LSP) Establishment Using Resource 
   ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, 
   February 2006. 

   7.2. Informative References 

   [GMPLS-OAM-REQ] Otani, T., et al., "OAM Requirements for Generalized 
   Multi-Protocol Label Switching (GMPLS) Networks", draft-ietf-ccamp-
   gmpls-oam-requirements-00.txt. 

    

 
 
Z. Ali, et al          Expires August 2008               [Page 16] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

Author's Addresses 

   Zafar Ali 
   Cisco Systems, Inc. 200 
   100 South Main St. # 
   Ann Arbor, MI 48104 
   USA 
   Email: zali@cisco.com 
    
   Marco Anisetti 
   University of Milan, Department of information Technology 
   Via Bramante 65, 26013 Crema (CR) 
   Italy 
   Email: anisetti@dti.unimi.it 
    
   Valerio Bellandi 
   University of Milan, Department of information Technology 
   Via Bramante 65, 26013 Crema (CR) 
   Italy 
   Email: bellandi@dti.unimi.it 

   Roberto Cassata 
   Cisco Systems, Inc. 
   Via Philips 2, 20052 Monza (MI) 
   Italy 
   Email: rcassata@cisco.com 
    
   Ernesto Damiani 
   University of Milan, Department of information Technology 
   Via Bramante 65, 26013 Crema (CR) 
   Italy 
   Email: damiani@dti.unimi.it 

   Francesco Diana 
   University of Milan, Department of information Technology 
   Via Bramante 65, 26013 Crema (CR) 
   Italy 
   Email: diana@dti.unimi.it 

   Tomohiro Otani  
   KDDI R&D Laboratories, Inc.  
   2-1-15 Ohara Fujimino Saitama, 356-8502. Japan  
   Email: otani@kddilabs.jp  
    

   Umberto Raimondi 

 
 
Z. Ali, et al          Expires August 2008               [Page 17] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

   University of Milan, Department of information Technology 
   Via Bramante 65, 26013 Crema (CR) 
   Italy 
   Email: uraimondi@crema.unimi.it 

 
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.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR 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 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 

Disclaimer of Validity 

   This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Copyright Statement 

   Copyright (C) The IETF Trust (2008). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
 
 
Z. Ali, et al          Expires August 2008               [Page 18] 

Internet-Draft  draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 
    

    

    











































 
 
Z. Ali, et al          Expires August 2008               [Page 19]