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

Versions: 00 01

CCAMP Working Group
Internet Draft
                                                             Zafar Ali
                                                       Roberto Cassata
                                                   Cisco Systems, Inc.
                                                        Marco Anisetti
                                                      Valerio Bellandi
                                                       Ernesto Damiani
                                                       Francesco Diana
                                                      Umberto Raimondi
                                                   University of Milan
                                                              T. Otani
                                           KDDI R&D Laboratories, Inc.
Category: Standard Track
Expires: May 02, 2009                                November 03, 2008

            draft-ali-ccamp-rsvp-te-based-evidence-collection-01.txt

                 RSVP-TE based impairments collection mechanism

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 May 02, 2009.




       Z. Ali, et al.     Expires May 24, 2009     [Page 1]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       Copyright Notice

       Copyright (C) The IETF Trust (2008).

    Abstract

       The problem of path validation of a pure light-path in a Dense
       Wavelength Division Multiplexing (DWDM) optical network
       requires the transmission of optical impairments related
       parameters along the provisioned route. In this draft we
       propose an RSVP-TE based mechanism to collect and evaluate
       optical impairments measured over optical nodes along the
       light-path.

       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.

    Table of Contents


    1. Introduction..................................................3
    2. Impairments Collection........................................3
       2.1. Optical Path Quality Evaluation..........................3
       2.2. Optical Impairments Classification and LSP Locking.......4
       2.3. Optical Impairments Collection...........................6
       2.4. Impairments Collection Request TLV.......................7
       2.5. Impairments recording TLV................................8
       2.6. Signaling Procedure for impairments collection using
       RSVP-TE.......................................................9
          2.6.1. Non-blocking impairments collection................10
          2.6.2. Blocking impairments collection with all nodes
          ready for impairments collection..........................11
          2.6.3. Blocking impairments collection with some
          node(s) blocked for impairments collection................12
    3. Security Considerations......................................12
    4. IANA Considerations..........................................13
    5. Acknowledgments..............................................13
    6. References...................................................13
       6.1. Normative References....................................13
       6.2. Informative References..................................13
    Author's Addresses..............................................14
    Intellectual Property Statement.................................15
    Disclaimer of Validity..........................................15

       Z. Ali, et al            Expires May 3, 2009         [Page 2]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08


1. Introduction

       For enhanced path status validation, we need mechanisms that
       can collect all physical impairments (consisting of optical
       measurements such as signal power, OSNR, etc.) that affect the
       light-path. The description of impairments type and effects
       [G.680] is out of the scope of this draft, we follow the
       description provided in [Bernstein-framework][Martinelli-frame].
       In this document we propose an RSVP-TE based mechanism for
       collection of impairments along a 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. In [RFC4054], an overview of some
       critical optical impairment and their routing related issues
       can be found.
       The term impairments refer to real optical measurements or
       estimates computed using a prediction model. The former may
       require mutually exclusive access to hardware to avoid
       interference, in which case the impairments required a
       blocking collection type. In the later case the impairments are
       collected with a non-blocking collection type. This draft
       addresses impairments collection for both blocking and non-
       blocking type leaving the definition of the collection type to
       as a section attribute.

2. Impairments Collection

       The line path validation mechanism needs to be aware of all
       physical impairments (consisting of optical measurements such
       as signal power, OSNR, Optical Channel Monitor, etc.) that
       affect the light-path. Consequently this draft proposes control
       plane based mechanism for impairments collection. How
       impairments are collected (from data plane) is beyond the scope
       of this document.

     2.1. Optical Path Validation

       Our approach is in full agreement with information model
       [Bernstein-info] for path validation and in particular we refer
       to [Bernstein-framework] for architectural options in which
       impairment validation for an optical path is defined.

       The validation of an optical path is assessed by collecting the
       physical impairments along an LSP and evaluating them. In this


       Z. Ali, et al            Expires May 3, 2009         [Page 3]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       draft we make use of the LSP_ATTRIBUTES to perform the
       impairments collection hop by hop along the optical path.

       It is important to note that collection of impairments in a
       blocking way requires a mutually exclusive access to the
       resource. Therefore the entire LSP needs to be "locked" until
       the collection for the impairments is completed. This implies
       that if another impairments collection process tries to
       retrieve impairments on the same node-resource already under
       "Administrative Impairments Locking" status, needs to be
       aborted. The draft uses the RSVP Admin status object to realize
       "LSP Administrative Impairments locking" to make sure that all
       nodes are ready to collect the impairments in a blocking way.

       Our RSVP based impairments collection protocol made the optical
       path validation described in [Berstain info] available.

       More in details the G.680 gives techniques and formulas for use
       in calculating the impact of a cascade of network elements.
       These formulations is at the base of our path validation.



       In the following we first define Optical Impairments collection
       classification, and the extensions to LSP ATTRIBUTE and RSVP
       Admin status objects needed to perform the aforementioned
       functionalities. Section 2.7 details the signaling mechanism
       with examples to illustrate how proposed extensions are used
       for impairments collection.

     2.2. Optical Impairments collection Classification and LSP Locking

       Physical impairments that have effect on the light-path can be
       collected in two ways:

       o  Blocking impairments collection. In general in the case of
       blocking collection, the impairment collection may require a
       mutually exclusive access to hardware resources while
       performing the measurement.

       o  Non blocking impairments collection. A collection of
       physical value that can be probed in parallel at different
       nodes.

       Consequently, every optical node can be in three states w.r.t.
       to a certain reserved resource: unlock, lock-requested or lock.
       In fact blocking collection of impairment requires the resource



       Z. Ali, et al            Expires May 3, 2009         [Page 4]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       to be in lock state. In general this is due to the hardware
       limitation of optical nodes.

       In case of blocking collection of impairments the LSP status
       needs to be set to "Locked". For this purpose, we extend the
       Admin object [RFC3471], [RFC3473] with B bit (Blocked request
       bit) and C bit (block Confirm bit). Specifically,
       Administrative status object is extended with the following two
       bits for locking purpose.

        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.

       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 the
       locking procedure is successfully ongoing.


       Z. Ali, et al            Expires May 3, 2009         [Page 5]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08


       During LSP locking for collection of impairments, the R bit
       (Reflect bit) MUST be set. Furthermore, if the node along the
       path understands B and C bits, the node MUST return the Admin
       object in the Resv Message for locking confirmation or
       unlocking. Since we need to block an entire LSP, any node
       unable to measure the required impairments MUST set a lock
       failure (unset the C bit in the Path Admin Object).

       The general locking procedure is defined as follows:

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

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

       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 Impairments Collection

       Path validation is based on holistic analysis of the
       impairments collected along the path of an LSP. To signal which
       impairments needs to be collected we extend the LSP Attribute
       TLV sub-object.

       The impairments 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
       impairments collection. The Path message also contains TLV sub-
       objects with required impairments.

       o  Every transit node, when receives the message with LSP
       Attribute object, assembles the collected impairments
       (specified in TLV) inside a sub-TLV. The way an optical node
       gets knowledge of the impairments using information locally


       Z. Ali, et al            Expires May 3, 2009         [Page 6]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       available at the node (e.g. via discovery of internal
       amplifiers, photodiode etc.) is out of the scope of this
       document.

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

       In case of blocking collection of impairments the LSP lock MUST
       be obtained before impairments collection.

       In case of non-blocking collection type, the unavailability of
       certain impairments in an intermediate node MUST NOT cause the
       request of failure. The holistic impairments evaluation SHOULD
       be able to deal with missing impairments.

       When a transit node not in locked state receives a request for
       blocking collection type, an impairments collection failure
       (PathErr) SHOULD be sent to the Ingress node.

     2.4. Impairments Collection Request TLV

       The proposed encoding scheme for optical impairments
       measurements defines a TLV associated to a particular
       impairments 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    |                    Reserved
       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       +-+

       Type: Collected impairments type (TBA). This can be blocking or
       non blocking type.



       Z. Ali, et al            Expires May 3, 2009         [Page 7]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

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

       E-type (Impairments Type, 8 bits): Impairments identifier
       encoded as per [WD6-23]. E.g., 0 for Signal power, 1 for OSNR,
       2 for Pilot Tone (as blocking impairments).

       This TLV defines which types of impairments (signal power,
       OSNR, Pilot Tone, alarm etc.) need to be collected and is
       carried by the Path message.

     2.5. Impairments recording TLV

       A set of impairments is collected through the Resv message to
       allow the evaluation at the ingress node. Each item of optical
       impairments is collected separately. Every transit node, in the
       Path message, finds the impairments Collection Requested TLV
       and replies the impairments value in Resv using impairments
       recording TLV (encoded in an LSP_ATTRIBUTES Object). The
       impairments value can be measured or estimated. Furthermore it
       sets the Measure Method inside this TLV according to the kind
       of measured media (single lambda measurement or aggregate
       measurement).

       This impairments collection improves the feasibility evaluation
       where network elements support at least a subset of
       impairments.

       The following TLV encodes the impairments values of the LSP
       associated to the impairments type defined in the impairments
       Collection Request TLV.



















       Z. Ali, et al            Expires May 3, 2009         [Page 8]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08



        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
       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       +-+
       |                         WavelengthID
       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       +-+
       |
       |
       //                 IPv4/IPv6 Address/unnumbered
       //
       |
       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       +-+
       |  Impairments Value
       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       +-+

       Type: Impairments type(TBA).

       Length: length of the TLV value in bytes.

       WavelengthID: encoded as per [WD6-23]. This field identifies
       the wavelength. If it is measured/estimated aggregate
       impairments, this field is set to 0.

       IPv4/IPv6 Address: The address of the Node that measures the
       impairments.

       Impairments Value: Estimated or measured impairments value
       according to [WD6-23]. E.g., the Signal Optical Power as 32-bit
       IEEE 754 floating point number.


     2.6. Signaling Procedure for impairments collection using RSVP-TE

       In this section we describe signaling procedures for path
       validation with impairments collection using examples. Consider


       Z. Ali, et al            Expires May 3, 2009         [Page 9]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       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 impairments
       collection and describe signaling procedures associated with
       the impairments collection and how above mentioned extensions
       to LSP Attribute and admin status objects are used for this
       purpose.

     2.6.1. Non-blocking collection of impairments

       The validation of an optical path is done after LSP is
       signaled. In case of non-blocking collection, the impairments
       collection follows the following procedure:

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

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

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

       o  Every transit node (OXC3,OXC2) inserts its own Impairments
       recording TLV inside Resv message in such way that ingress node
       collects all required impairments hop by hop.


       Z. Ali, et al            Expires May 3, 2009        [Page 10]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       o  OXC1 node when receives the Resv message extract the
       impairments recording TLV to perform holistic path validation.

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

       Summarizing the Impairments Collection will be executed by the
       returning Resv message that collects hop-by-hop impairments
       objects upstream.

     2.6.2. Blocking collection of impairments with all nodes ready for
       impairments collection

       In this scenario the locking strategy needs to be performed
       first to ensure that no node in the LSP is already locked in
       another blocking collection. I.e., we need to be sure that all
       nodes along the path are ready to collect the impairments. This
       phase uses Admin status object in the Path and Resv message, as
       follows:

       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 to signal locking is required. C bit is used for
       locking confirmation. Recall it needs to be set if lock is
       granted, and needs to be unset otherwise.

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

       o  Egress node OXC4 switches to lock state and forwards 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 state to "locked".

       o  Ingress node OXC1 when receives the Resv message with Admin
       status object with B and C bit set switches to "locked" state.

       At the end of this procedure the entire LSP is in "locked"
       state and is ready for impairments collection.

       At this stage the Impairments Collection can be performed as
       described earlier.




       Z. Ali, et al            Expires May 3, 2009        [Page 11]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

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

     2.6.3.  Blocking collection of impairments with some node(s)
       blocked for impairments collection.

       In this scenario the locking procedure fails since some node
       (OXC3 in this example) is in "locked" or "lock-required" state
       over another 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 to signal locking is required. C bit is used for
       locking confirmation. Recall it needs to be set if lock is
       granted, and needs to be unset otherwise.

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

       o  OXC3 node receives the Admin status object and, since it is
       already in lock or lock-required state for another LSP with the
       same resources, unsets the C bit. Therefore the locking
       procedure will fail.

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

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

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

       At this stage the Locking mechanism fails since the ingress
       node has not received the confirmation of successful locking (C
       bit set).




       Z. Ali, et al            Expires May 3, 2009        [Page 12]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

3. Security Considerations

   Security considerations and requirements from [RFC4379] apply
   equally to this document. Furthermore, there are some
   additional security considerations that may be induced by the
   extended RSVP-TE model proposed by this draft. These security
   considerations will be added in a later version of the draft.

4. IANA Considerations

   IANA considerations are to be added in a later revision.

5. Acknowledgments

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

6. References

   6.1. Normative References

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

       [RFC3473]  Berger, L., "Generalized Multi-Protocol Label
       Switching (GMPLS) Signaling Resource ReserVation Protocol-
       Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January
       2003.

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

       [G.680] ITU-T Recommendation G.680, Physical transfer functions
       of optical network elements, July 2007.

    6.2. Informative References

       [RFC4054] Strand, J., Ed., and A. Chiu, Ed., "Impairments and
       Other Constraints on Optical Layer Routing", RFC 4054, May
       2005.

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

       [WD6-23] Cassata, R., Damiani, E., Optical Parameters
       Classification and Encoding. ITU-T contribution.

       Z. Ali, et al            Expires May 3, 2009        [Page 13]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

       [Bernstein-framework] G. Bernstein, Y. Lee, D. Li, A Framework
       for the Control and Measurement of Wavelength Switched Optical
       Networks (WSON) with Impairments, Work in Progress, October
       2008.

       [Bernstein-info] G. Bernstein, Y. Lee, D. Li, Information Model
       for Impaired Optical Path Validation, Work in progress, October
       2008

       [Martinelli-frame] G. Martinelli, A. Zanardi, D. Bianchi, E.
       Davies, A Framework for definining Optical Impariments to be
       used in WSON networks through GMPLS

       Author's Addresses

       Zafar Ali
       Cisco systems, Inc.,
       2000 Innovation Drive
       Kanata, Ontario, K2K 3E8
       Canada.
       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

       Z. Ali, et al            Expires May 3, 2009        [Page 14]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08

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

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

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


7. Intellectual Property Considerations

   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.

       Z. Ali, et al            Expires May 3, 2009        [Page 15]


        draft-ali-ccamp-rsvp-te-based-evidence-collection-01   Nov. 08


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

9. 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 May 3, 2009        [Page 16]


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