One document matched: draft-jounay-pwe3-leaf-initiated-p2mp-pw-01.txt
Differences from draft-jounay-pwe3-leaf-initiated-p2mp-pw-00.txt
Network Working Group F. Jounay
Internet Draft J.L. Le Roux
Category: Standards Track P. Niger
Expires: April 2009 France Telecom
Y. Kamite
NTT Communications
November 3, 2008
LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire
draft-jounay-pwe3-leaf-initiated-p2mp-pw-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 April 3, 2009.
Abstract
This document provides a solution to extend LDP signaling in order to
allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP
PW). Such an extension of existing point to point Pseudowire is made
necessary by new applications. The document deals with the leaf-
initiated P2MP PW setup and maintenance. The processing for setting
up a P2MP MS-PW is built on the processing for setting up a P2MP LSP
with LDP.
Jounay et al. Expires April 3, 2009 [Page 1]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
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 [RFC2119].
Table of Contents
1. Terminology.....................................................3
2. Preliminary Notes...............................................3
3. Introduction....................................................3
4. P2MP SS-PW Setup Mechanism......................................3
5. P2MP MS-PW Setup Mechanism......................................4
5.1. P2MP MS-PW Reference Model....................................4
5.2. Overview of the P2MP MS-PW Setup..............................5
5.3. P2MP FEC Element for MS-PW Setup..............................5
5.3.1. P2MP GID FEC Element........................................5
5.3.2. Optional TAII Leaf Sub-TLV..................................6
5.4. Configuration.................................................6
5.5. Capability Negotiation Procedure..............................6
5.6. Signaling for P2MP MS-PW......................................7
5.6.1. Label Map...................................................7
5.6.1.1. Determining one's 'upstream PE'...........................8
5.6.1.2. Egress T-PE Operation.....................................8
5.6.1.3. Branch S-PE Operation.....................................8
5.6.1.4. Ingress T-PE Operation....................................8
5.6.2. Label Withdraw..............................................8
5.6.2.1. Egress T-PE Operation.....................................8
5.6.2.2. Branch S-PE Operation.....................................9
5.6.2.3. Ingress T-PE Operation....................................9
5.6.2.4. Upstream PE Change........................................9
5.7. Using TAII Leaf Sub-TLV.......................................9
6. Security Considerations.........................................9
7. IANA Considerations............................................10
7.1. LDP FEC Type.................................................10
7.2. LDP TLV Type.................................................10
7.3. LDP Status Codes.............................................10
8. Acknowledgments................................................10
9. References.....................................................10
9.1. Normative References.........................................10
9.2. Informative References.......................................11
Authors' Addresses................................................11
Intellectual Property and Copyright Statements....................12
Jounay et al. Expires April, 2009 [Page 2]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
1. Terminology
This document uses acronyms and terminologies defined in [RFC5036],
[RFC3985], [P2MP PW REQ] and [RFC5254].
2. Preliminary Notes
The current version of the document does not cover:
- Source-initiated unidirectional P2MP PW setup, Source-initiated
grafting/pruning. This mode is described in a separate document
[SOURCE INIT P2MP PW].
- The mechanism for the leaves to discover the P2MP FEC identifying
the P2MP MS-PW is out of the scope of this document.
- The P2MP PW Upstream Label Assignment required when the underlying
layer is a P2MP LSP. This mode and detailed procedures will be
described in a future version. This document describes LDP extensions
for setting up P2MP MS-PW where the PW segments are supported over
P2P PSN tunnels.
The Working Group feedback is required on the points described above.
3. Introduction
[P2MP PW REQ] describes a set of requirements for setting up a P2MP
PW setup. In the MS-PW architecture, the underlying layer which
supports a PW segment belonging to the PW tree may be either a P2P or
a P2MP PSN tunnel.
This document describes LDP extensions for setting up P2MP MS-PW
where the PW segments are supported over P2P PSN tunnels.
For that purpose a new P2MP GID FEC element is defined to encode MS-
PW parameters. The procedures for setting up a P2MP MS-PW are built
on LDP mechanisms for setting P2MP LSP [MLDP], where hops are here S-
PEs and T-PEs. Therefore a leaf can join the tree by sending a Label
Map associated to this FEC towards the root.
The support of the underlying P2MP PSN tunnels will be described in a
future version.
4. P2MP SS-PW Setup Mechanism
This section will be described in a future version.
Jounay et al. Expires April, 2009 [Page 3]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
5. P2MP MS-PW Setup Mechanism
5.1. P2MP MS-PW Reference Model
Figure 1 describes the P2MP MS-PW reference model which is derived
from [P2MP PW REQ] to support P2MP emulated services.
|<-----------P2MP MS-PW------------>|
Native | P2P P2P | Native
Service | |<-PSN1-->| |<-PSN2-->| | Service
(AC) V V tunnels V V tunnels V V (AC)
| +----+ +-----+ +----+ |
| |T-PE| |S-PE1|=========|T-PE| | +----+
| | 1 | | .......PW3......2.|-----------|CE2 |
| | |=========| . |=========| | | +----+
| | .......PW1....... | +----+ |
| | . |=========| . | +----+ |
| | . | | . |=========|T-PE| | +----+
| | . | | .......PW4......3.|-----------|CE3 |
+----+ | | . | | |=========| | | +----+
|CE1 |---------|.. | +-----+ +----+ |
+----+ | | . | +-----+ +----+ |
| | . | |S-PE2|=========|T-PE| | +----+
| | . | | .......PW5......4.|-----------|CE4 |
| | . | | . |=========| | | +----+
| | . |=========| . | +----+ |
| | .......PW2....... +----+ |
| | |=========| . |=========|T-PE| | +----+
| | | | .......PW6......5.|-----------|CE5 |
| | | | |=========| | | +----+
| +----+ +-----+ +----+ |
Figure 1 P2MP MS-PW over P2P PSN tunnels Reference Model
Figure 1 describes the P2MP MS-PW reference model which is extracted
from [P2MP PW REQ] where the PW segments are supported over
individual P2P PSN tunnels. Here in a P2MP MS-PW configuration the S-
PE is responsible for switching a MS-PW from one input P2P segment to
one or several output P2P segments.
Referring to Figure 1 T-PE1 is the Ingress T-PE and T-PE2, T-PE3, T-
PE4 and T-PE5 are the Egress T-PEs. The S-PE S-PE1 and S-PE2 play the
role of branch S-PE since they are in charge of switching the input
P2P PW1 and the P2P PW2 segment to respectively the output P2P PW3,4
and the output P2P PW5,6 segments.
Note that a P2MP MS-PW may obviously transit trough more than one S-
PE along its path.
Jounay et al. Expires April, 2009 [Page 4]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
5.2. Overview of the P2MP MS-PW Setup
The P2MP MS-PW setup relies on the use of the P2MP GID FEC Element
defined also in [SOURCE INIT P2MP PW]. The solution aims at setting
up a unidirectional P2MP MS-PW.
The principle proposed here relies on a leaf-initiated P2MP MS-PW
setup. In the proposed approach the leaf is assumed to know the P2MP
PW FEC which contains the source AII address and the P2MP Identifier.
The procedure used for the P2MP GID FEC discovery by the leaves is
out of scope of this document.
The document describes the solution to setup the P2MP MS-PW in the
case the PW segments are supported individually over a P2P PSN
tunnel. After a negotiation procedure between Ingress T-PE/S-PE and
S-PE/Egress T-PEs to verify their P2MP PW FEC capability, the Egress
T-PE sends a Label Map to its upstream PE selected to reach the SAII
specified in the P2MP GID FEC. At turn the S-PE carries on the
signalling procedure by sending if required a new Label Map towards
its next hop to reach the source SAII. In the MS-PW architecture, the
hop consists either in a branch S-PE or the Ingress T-PE. Each PE
receiving the P2MP FEC installs a forwarding state to map traffic
into the P2MP MS-PW.
5.3. P2MP FEC Element for MS-PW Setup
5.3.1. P2MP GID FEC Element
The P2MP GID FEC structure is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP GID (TBD)|C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP Id | Length | P2MP Id Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P2MP Id Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jounay et al. Expires April, 2009 [Page 5]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
5.3.2. Optional TAII Leaf Sub-TLV
A TAII Leaf sub-TLV is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| TAII Leaf Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ ------------------- ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the Egress T-PE sends Label Map message, it MAY optionally add
the TAII Leaf sub-TLV to carry the information regarding the leaves
which initiates the message. The leaves are the TAII configured on
this Egress T-PE.
5.4. Configuration
After configuring on each T-PE the attached AIIs, it is assumed that
all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW
routing table which gives for each AII as entry the "next hop" to
reach that AII. This AII routing table can be filled manually or
updated dynamically by means of some extended routing protocol like
proposed in [DYN MS-PW]. The construction of the table is out of
scope of the present document.
Each PE relies on its AII PW routing table to select the next hop PE
(S-PE or T-PE) to reach a given AII.
5.5. Capability Negotiation Procedure
To achieve the capability negotiation the solution MUST follow the
LDP capability advertisement mechanism described in [LDP CAPA]. New
code points are required and MUST be defined.
Jounay et al. Expires April, 2009 [Page 6]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
The PEs belonging to a given P2MP MS-PW MUST support the P2MP GID FEC
Element used by LDP to setup the P2MP MS-PW.
The PEs MUST also negotiate with their remote PEs the capability of
supporting the PW status TLV. This negotiation is a key element in
order to allow these PEs to announce some status information later
on.
5.6. Signaling for P2MP MS-PW
This section is directly extracted from [MLDP] and adapted to the
setup of MS-PW.
It defines the rules for the processing and propagation of the P2MP
FEC Element for the Leaf-initiated P2MP MS-PW setup. The following
notation is derived from [MLDP] and is used in the processing rules:
1. P2MP GID FEC Element <X, Y, Y'>: a FEC Element with SAII X, AGI Y
and P2MP Id Y'.
2. P2MP PW Label Map <X, Y, Y', L>: a Label Map message with a FEC
TLV with a single P2MP GID FEC Element <X, Y, Y'> and Label TLV with
label L.
3. P2MP PW Label Withdraw <X, Y, Y', L>: a Label Withdraw message
with a FEC TLV with a single P2MP GID FEC Element <X, Y, Y'> and
Label TLV with label L.
4. P2MP MS-PW <X, Y, Y'> (or simply <X, Y, Y'>): a P2MP MS-PW with
SAII X, AGI Y and P2MP Id Y'.
5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on branch S-
PE S means that on receiving a packet with label L', S makes n copies
of the packet. For copy i of the packet, S swaps L' with Li and
sends it out over interface Ii.
The procedures below are organized by the role which the PE plays in
the P2MP MS-PW. T-PE Z knows that it is an Egress T-PE by a discovery
process which is outside the scope of this document. A T-PE is
defined as an Egress T-PE if one or several leaf AIIs are configured.
During the course of protocol operation, the Ingress T-PE recognizes
its role because it owns the SAII of the PW tree.
5.6.1. Label Map
The following lists procedures for generating and processing P2MP
Label Map messages for PEs participating in a P2MP MS-PW.
For the approach described here we use downstream assigned labels.
Jounay et al. Expires April, 2009 [Page 7]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
5.6.1.1. Determining one's 'upstream PE'
A PE Z that is part of P2MP MS-PW <X, Y, Y'> determines the T-LDP
peer U which lies on the best path from Z to the SAII. The path
selection is achieved by means of the AII PW routing table. U is Z's
"Upstream PE" for <X, Y, Y'>.
5.6.1.2. Egress T-PE Operation
An Egress T-PE Z of P2MP MS-PW <X, Y, Y'> determines its upstream PE
U for <X, Y, Y'>, allocates a label L, and sends a P2MP PW Label Map
<X, Y, Y', L> to U.
5.6.1.3. Branch S-PE Operation
Suppose a branch S-PE Z receives a P2MP PW Label Map <X, Y, Y', L>
from LDP peer T. Z checks whether it already has state for <X, Y,
Y'>. If not, Z allocates a label L', and installs state to swap L'
with L over interface I associated with peer T. Z also determines its
upstream PE U for <X, Y, Y'> and sends a P2MP PW Label Map <X, Y, L'>
to U.
If Z already has state for <X, Y, Y'>, then Z does not send a Label
Map message for P2MP MS-PW <X, Y, Y'>. All that Z needs to do in
this case is to update its forwarding state. Assuming its old
forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new
forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I,
L>}.
5.6.1.4. Ingress T-PE Operation
Suppose the Ingress T-PE Z receives a P2MP Label Map <X, Y, Y', L>
from peer T. Z checks whether it already has forwarding state for <X,
Y, Y'>. If not, Z creates forwarding state to push label L onto the
traffic that Z wants to forward over the P2MP MS-PW.
If Z already has forwarding state for <X, Y, Y'>, then Z adds "push
label L, send over interface I" to the nexthop, where I is the
interface associated with peer T.
5.6.2. Label Withdraw
The following lists procedures for generating and processing P2MP PW
Label Withdraw messages for PEs that participate in a P2MP MS-PW.
5.6.2.1. Egress T-PE Operation
If an Egress T-PE Z discovers that it has no longer leaves AII
belonging to the P2MP MS-PW, it SHOULD send a P2MP PW Label Withdraw
Jounay et al. Expires April, 2009 [Page 8]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
<X, Y, Y', L> to its upstream PE U for <X, Y, Y'>, where L is the
label it had previously advertised to U for <X, Y, Y'>.
5.6.2.2. Branch S-PE Operation
If a branch S-PE Z receives a P2MP PW Label Withdraw message <X, Y,
L> from a node W, it deletes label L from its forwarding state, and
sends a P2MP PW Label Release message with label L to W.
If deleting L from Z's forwarding state for P2MP MS-PW <X, Y, Y'>
results in no state remaining for <X, Y, Y'>, then Z propagates the
P2MP PW Label Withdraw for <X, Y, Y'>, to its upstream T, by sending
a P2MP PW Label Withdraw <X, Y, Y', L1> where L1 is the label Z had
previously advertised to T for <X, Y, Y'>.
5.6.2.3. Ingress T-PE Operation
The procedure when the Ingress T-PE of a P2MP MS-PW receives a P2MP
PW Label Withdraw message are the same as for branch S-PE, except
that it would not propagate the P2MP PW Label Withdraw upstream (as
it has no upstream).
5.6.2.4. Upstream PE Change
If, for a given PE Z participating in a P2MP MS-PW <X, Y, Y'>, the
upstream PE changes, say from U to U', then Z MUST update its
forwarding state by deleting the state for label L, allocating a new
label, L', for <X,Y, Y'>, and installing the forwarding state for L'.
In addition Z MUST send a P2MP PW Label Map <X, Y, Y', L'> to U' and
send a P2MP PW Label Withdraw <X, Y, Y', L> to U.
5.7. Using TAII Leaf Sub-TLV
Section TBD
The TAII Leaf sub-TLV MAY be optionally used when a leaf joins the PW
tree to announce to the source that it is part from the PW tree. If
this option is chosen, the Egress T-PE adds to the FEC Element this
TAII sub-TLV in the Label Map message. As soon as in the source
direction a Label Map is not required since for instance a S-PE
already maintains a state for this MS-PW tree, the information
related to the Leaf TAIIs is retrieved from the TAII Leaf sub-TLV and
is propagated by means of a LDP Notification message up to the
corresponding Ingress T-PE.
6. Security Considerations
This section will be added in a future version.
Jounay et al. Expires April, 2009 [Page 9]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
7. IANA Considerations
7.1. LDP FEC Type
This document uses a new FEC element type FEC P2MP GID , from the
"FEC Type Name Space" for the label Distribution Protocol (LDP RFC
3036).
The following values are suggested for assignment:
FEC P2MP GID : 0x83
7.2. LDP TLV Type
This document uses several new LDP TLV types; IANA already maintains
a registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The
following values are suggested for assignment:
Sub-TLV Leaf TAII
7.3. LDP Status Codes
This document uses several new LDP status codes; IANA already
maintains a registry of name "STATUS CODE NAME SPACE" defined by
RFC5036. The following values are suggested for assignment:
Range/Value E Description Reference
------------- ----- ---------------------- ---------
LDP Capabilities
8. Acknowledgments
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
Thomas, B., "LDP Specification", October 2007.
[RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005
[RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for
inter domain Pseudo-Wires", October 2008
Jounay et al. Expires April, 2009 [Page 10]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
9.2. Informative References
[P2MP PW REQ] Jounay, F., Niger, P., Kamite, Y., Martini, L.,
Heron, G., Wang, L., Delord, .S, "Use Cases and
signaling requirements for Point-to-Multipoint
PW", Internet Draft, draft-ietf-pwe3-p2mp-pw-
requirements-00.txt, September 2008
[DYN MS-PW] Balus, F., Bocci, M., Martini. L, " Dynamic
Placement of Multi Segment Pseudo Wires",
Internet Draft, draft-ietf-pwe3-dynamic-ms-pw-
08.txt, July 2008
[MLDP] Minei, I., Kompella, K., Thomas, B., Wijnands,
I. "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths", Internet
Draft, draft-ietf-mpls-ldp-p2mp-05, May 2008
[LDP CAPA] Aggarwal, R., Le Roux, JL., Thomas, B., "LDP
Capabilities" draft-thomas-mpls-ldp-
capabilities-02.txt, April 2008
[SOURCE INIT P2MP PW] Jounay, F., Niger, P., Kamite, Y., "LDP
Extensions for Source-initiated Point-
to-Multipoint Pseudowire" draft-jounay-
niger-pwe3-source-initiated-p2mp-pw-
01.txt, November 2008
Author's Addresses
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
Jounay et al. Expires April, 2009 [Page 11]
Internet Draft Leaf-initiated P2MP PW Setup November 2008
FRANCE
Email: philippe.niger@orange-ftgroup.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Email: y.kamite@ntt.com
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.
Jounay et al. Expires April, 2009 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 17:41:08 |