One document matched: draft-ali-ccamp-rsvp-te-based-evidence-collection-00.txt
CCAMP Working Group Zafar Ali
Roberto Cassata
Internet Draft Cisco Systems, Inc.
Intended status: Standards Track Marco Anisetti
Valerio Bellandi
Ernesto Damiani
Francesco Diana
Umberto Raimondi
University of Milan
T. Otani
KDDI R&D Laboratories, Inc.
Expires: January 04, 2009 July 05, 2008
draft-ali-ccamp-rsvp-te-based-evidence-collection-00.txt
An RSVP-TE based Evidence 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 January 04, 2009.
Z. Ali, et al. Expires Jan. 04, 2009 [Page 1]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The problem of quality analysis and advanced fault detection of
a pure light-path in a Dense Wavelength Division Multiplexing
(DWDM) optical network requires the transmission of optical
evidence related parameters along the provisioned route. In
this draft we propose an RSVP-TE based mechanism to collect and
evaluate optical evidence 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. Evidence Collection........................................3
2.1. Optical Path Quality Evaluation.......................3
2.2. Optical Evidence Classification and LSP Locking.......4
2.3. Optical Evidence Collection...........................6
2.4. Evidence Collection Request TLV.......................7
2.5. Evidence recording TLV................................7
2.6. Signaling Procedure for evidence collection using RSVP-
TE........................................................10
2.6.1. Non-blocking evidence collection................10
2.6.2. Blocking evidence collection with all nodes ready
for evidence collection................................11
2.6.3. Blocking evidence collection with some node(s)
blocked for evidence collection........................12
3. Security Considerations...................................13
4. IANA Considerations.......................................13
5. Acknowledgments...........................................13
6. References................................................13
6.1. Normative References.................................13
6.2. Informative References...............................14
Author's Addresses...........................................14
Intellectual Property Statement..............................15
Disclaimer of Validity.......................................15
Z. Ali, et al Expires January 5, 2009 [Page 2]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
1. Introduction
For successful fault detection on a light-path, we need
mechanisms that can collect all physical evidences (consisting
of optical measurements such as signal power, OSNR, etc.) that
affect the light-path. In this document we propose an RSVP-TE
based mechanism for collection of evidences 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.
The term evidence refers 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 evidence is called blocking
evidence. In the later case the evidence is classified as non-
blocking. This draft addresses evidence collection for both
blocking and non-blocking evidences.
2. Evidence Collection
For successful fault detection on an optical path, the fault
isolation mechanism needs to be aware of all physical evidence
(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 evidence collection. How evidences are collected (from data
plane) is beyond the scope of this document.
2.1. Optical Path Quality Evaluation
The quality of an optical path is assessed by collecting the
physical evidences along an LSP and evaluating them (e.g. for
faulty point detection). In this draft we make use of the
LSP_ATTRIBUTES to perform the evidence collection hop by hop
along the optical path.
It is important to note that collection of blocking evidences
require a mutually exclusive access to the resource. Therefore
the entire LSP needs to be "locked" until the collection for
the blocking evidences is completed. This implies that if
another evidence collection process tries to retrieve evidences
on the same node-resource already under "Administrative
Evidences Locking" status, needs to be aborted. The draft uses
Z. Ali, et al Expires January 5, 2009 [Page 3]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
the RSVP Admin status object to realize "LSP Administrative
Evidences locking" to make sure that all nodes are ready to
collect the blocking evidence.
In the following we first define Optical Evidence
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 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. A 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 evidence requires the resource to be in lock
state. 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". 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|
Z. Ali, et al Expires January 5, 2009 [Page 4]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
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.
During LSP locking for collection of blocking evidence, 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 blocking evidence 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 blocking evidence.
Z. Ali, et al Expires January 5, 2009 [Page 5]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
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 Evidence Collection
Path quality evaluation is based on holistic analysis of the
evidence collected along the path of an LSP. To signal which
evidence needs to be collected we extend the 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. The Path message also contains TLV sub-objects 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 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 evidence the LSP lock MUST be obtained
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. The holistic evidence evaluation SHOULD be able to
deal with missing non-blocking evidence.
Z. Ali, et al Expires January 5, 2009 [Page 6]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
When a transit node not in locked state receives a request for
blocking evidence, an evidence collection failure (PathErr)
SHOULD be sent to the Ingress node.
2.4. Evidence Collection Request TLV
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 | Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type: Collected evidence type (TBA). This 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 encoded as
per [WD6-23]. E.g., 0 for Signal power, 1 for OSNR, 2 for Pilot
Tone (as blocking evidence).
This TLV defines which types of evidence (signal power, OSNR,
Pilot Tone, alarm etc.) need to be collected and is carried by
the Path message.
2.5. Evidence recording TLV
A set of evidence is 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 replies the Evidence value in Resv using
Z. Ali, et al Expires January 5, 2009 [Page 7]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
evidence recording TLV (encoded in an LSP_ATTRIBUTES Object).
The evidence 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 evidence collection improves the feasibility evaluation
where network elements support at least a subset of evidence.
The following TLV encodes the evidence values of the LSP
associated to the evidence type defined in the Evidence
Collection Request TLV.
Z. Ali, et al Expires January 5, 2009 [Page 8]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 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
//
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Evidence Value
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type: Evidence 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 evidence,
this field is set to 0.
IPv4/IPv6 Address: The address of the Node that measures the
evidence.
Evidence Value: Estimated or measured evidence value according
to [WD6-23]. E.g., the Signal Optical Power as 32-bit IEEE 754
floating point number.
Z. Ali, et al Expires January 5, 2009 [Page 9]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
2.6. Signaling Procedure for evidence collection using RSVP-TE
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.6.1. Non-blocking evidence collection
The quality evaluation of an optical path is done after LSP is
signaled. In case of non-blocking evidences, evidence
collection follows the following procedure:
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 Every transit node (OXC2,OXC3), when receives the Path
message with Evidence Collection Request TLV, starts 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 does 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
Z. Ali, et al Expires January 5, 2009 [Page 10]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
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.
o OXC1 node when receives the Resv message extract the
Evidences recording TLV to perform holistic path quality
analysis.
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.
Summarizing the Evidence collection will be executed by the
returning Resv message that collects hop-by-hop evidence
objects upstream.
2.6.2. Blocking evidence collection with all nodes ready for
evidence 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 evidences collection. I.e., 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, 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
blocking evidence.
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".
Z. Ali, et al Expires January 5, 2009 [Page 11]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
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 blocking evidence collection.
At this stage the Evidence collection can be performed as
described earlier.
The locking 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.6.3. Blocking evidence collection with some node(s) blocked for
evidence 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 blocking evidence.
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.
Z. Ali, et al Expires January 5, 2009 [Page 12]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
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).
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
TBA
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.
Z. Ali, et al Expires January 5, 2009 [Page 13]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
6.2. Informative References
[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.
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
Francesco Diana
Z. Ali, et al Expires January 5, 2009 [Page 14]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
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
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
Z. Ali, et al Expires January 5, 2009 [Page 15]
draft-ali-ccamp-rsvp-te-based-evidence-collection.doc July 08
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 January 5, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 05:50:28 |