One document matched: draft-ali-ccamp-rsvp-te-based-evidence-collection-01.txt
Differences from draft-ali-ccamp-rsvp-te-based-evidence-collection-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-24 07:17:30 |