Network Working Group F. Jounay
Internet Draft P. Niger
Category: Standards Track France Telecom
Expires: May 2008
Y(J) Stein
RAD Data
Communications
H. Shah
Ciena Corp
November 12, 2007
Dynamic Update of PW Parameters
draft-jounay-pwe3-dynamic-pw-update-00.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.
Abstract
This draft aims at providing a generic solution for updating PW
characteristics (interface parameters, label) on-the-fly without
service interruption. The document specifies a new generic PWE
control protocol mechanism called the PW Update. A PW Update LDP
sub-TLV is defined for that purpose. It defines the signaling
extension and describes the procedures to dynamically update the PW
parameters. A use case is provided for CESoPSN PWs.
Jounay et al. Expires August 26, 2007 [Page 1]
Internet Draft Dynamic Update of PW parameters November 2007
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. Terminology.....................................................3
2. Introduction....................................................3
3. Motivation......................................................3
4. Overview of the solution........................................3
5. PW Update LDP TYPE TLV..........................................5
6. Generic PW Capacity Update......................................6
6.1. Update Procedure............................................6
6.2. PW Update Mechanism Reference Model.........................7
6.3. Control Plane...............................................7
6.4. Data Plane..................................................8
7. Use Case: CESoPSN...............................................8
7.1. Interface Parameters for CESoPSN PWs................... ....9
7.1.1. CEP/TDM Payload Bytes (0x04)............................9
7.1.2. CEP/TDM Bit-Rate (0x07).................................9
7.2. CESoPSN Interface Parameters Update Mechanism Reference....10
7.3. Control Plane..............................................10
7.4. Data Plane.................................................11
8. MS-PW Applicability............................................11
9. Pseudowire Update Backward Compatibility.......................11
10. Security Considerations.......................................12
11. IANA Considerations...........................................12
11.1. LDP TLV Type..............................................12
11.2. LDP PW Update Codes.......................................12
12. Acknowledgments...............................................12
13. References....................................................13
13.1. Normative References......................................13
13.2. Informative References....................................13
Jounay et al. Expires May 12, 2008 [Page 2]
Internet Draft Dynamic Update of PW parameters November 2007
1. Terminology
The document uses terminology defined in [RFC4447], [PW TDM CTRL].
2. Introduction
This draft aims at providing a generic solution for on-the-fly
updating of PW characteristics (interface parameters, PW label)
without service interruption.
Section 5 specifies a new LDP TYPE TLV, PW Update sub-TLV, which is
used to advertise the parameters (interface parameters, label..) to
be changed.
Section 6 defines the related signaling extension and describes the
procedures to update dynamically the PW characteristics.
Section 7 provides an example use-case, for CESoPSN PWs.
3. Motivation
The specification of a PW update mechanism is motivated by the need
to update a PW parameters, while avoiding service disruption. That
is particularly valuable for voice service applications, for
example, mobile backhauling. Although interface parameter update
will generally be a rare event for most applications, it is still
highly recommended not to negatively impact customer services. This
is even truer when the number of customers already in use is
significant.
Alternatives to PW parameter update are available when facing
traffic evolution. For instance, it would be possible to setup a new
PW dedicated to handle the traffic overload. However, this scenario
does not scale since each update would result in setting up a new
PW, leading to management fragmentation.
4. Overview of the solution
The proposed solution is only applicable to the Generalized PWid FEC
element. This is because we desire to change some of the interface
parameters while keeping the same PW FEC element. Note that the PWid
FEC element described in [RFC4447] includes the interface parameters
and so does not allow maintaining the FEC. The update mechanism with
PWid FEC element is left for further study.
Jounay et al. Expires May 12, 2008 [Page 3]
Internet Draft Dynamic Update of PW parameters November 2007
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
|Attachment| |<-- PSN Tunnel -->| |Attachment|
| Circuit V V V V Circuit |
V (AC) +----+ +----+ (AC) V
+-----+ | | PE1|==================| PE2| | +-----+
| | | | | | | | | |
| CE1 |----------|............PW1.............|----------| CE2 |
| | | | | | | |
+-----+ | |==================| | +-----+
+----+ +----+
LLM (FEC1, L1, int. Par.)
----------------------->
LLM (FEC1, L2, int. Par.)
<-----------------------
Figure 1 Reference Model
Referring to Figure 1, PE1 is assumed as the ingress PE, and so
initiates the first LDP Label Mapping (LLM) message. PE2 is assumed
as the egress PE. The interface parameters included in the LLM
message allow the egress PE to be informed of the payload format
used by the ingress PE. The egress PE forwards the payload received
from CE2 in the appropriate format with the PW Label L1 to the
ingress PE. The Label L1 carries the (forwarding) semantics for the
ingress PE to correctly forward the traffic to CE1 over its local
AC. The same process applies in the reverse direction for the
traffic from the ingress PE to the egress PE.
Let's assume that some time after CE1 and CE2 have been in
communications, the need arises to change the traffic bandwidth.
This warrants a mechanism whereby operator can adjust the PW
capacity without incurring service disruption. We describe below how
the sequence of events at the control plane and data plane is
coordinated to bring about this capacity adjustment with no service
disruption. The concept employed is "make-before-break".
Control plane: The method consists of re-advertising the new
interface parameters in a new LLM message. The LLM message may also
carry a new label in addition to the updated interface parameters
for the same PW FEC element. A new LDP TLV Type is defined to
identify the update purpose of this LLM message, since otherwise the
new mapping of an already advertised FEC would be rejected. The PW
Update sub-TLV is included in the LLM message with the interface
parameters codes that are changed. The receiving PE verifies the
updates and acknowledges the acceptance by reciprocating the LLM
message to the sender.
Jounay et al. Expires May 12, 2008 [Page 4]
Internet Draft Dynamic Update of PW parameters November 2007
Note that if the If asymmetric parameters are allowed such that
egress PE2 does not need to increase the b/w then there is no need
to acknowledge the acceptance. LLM messages are assumed accepted
unless corresponding LDP label release is received.
Data plane: Upon reception of the new LLM message the egress PE
sends the traffic in the new format while initiating the new LLM
message for the reverse direction. Note that the possible new
assigned Label is required to allow the ingress PE to detect in-band
the traffic corresponding to the new format. Therefore the ingress
PE is capable of forwarding traffic correctly over its local AC in
its new format, since it recognizes the new Label it assigned and
previously advertised.
5. PW Update LDP TYPE TLV
The PW Update LDP sub-TLV is included in the LLM message to identify
its update role, thus allowing the receiving PE to accept the new
interface parameters and also the possible new Label required for
the in-band detection.
The PW Update sub-TLV has the following format:
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| PW Update Type (0x096D)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++
| Update Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 PW Update sub-TLV
U = 1 F= 0 implies that a legacy PE must silently discard the TLV.
The PW Update sub-TLV MUST be included in the Label Mapping message
generated by a PE to update some PW characteristics.
The TLV information length field contains the length of the update
code, namely the number of parameters to be updated in octets. Hence
the number of parameters to be changed included in the PW Update is
deduced from this field.
The Update Code indicates the parameters that must be updated. Two
update code are identified for the purpose of this document
(interface parameters iP, PW Label L).
(IANA assignment required).
Jounay et al. Expires May 12, 2008 [Page 5]
Internet Draft Dynamic Update of PW parameters November 2007
The PW Update sub-TLV is carried as follows in the Label Mapping
message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Generalized ID FEC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Update TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 PW Update sub-TLV in LLM
Note that the new values of the PW interface parameters defined in
[RFC4446] are indicated in the classic fields (i.e. the Interface
parameters sub-TLV as defined in [RFC4447]).
6. Generic PW Capacity Update
6.1. Update Procedure
Two possible scenarios are possible when the PW capacity is
renegotiated, i.e. increase or decrease the PW capacity via the
interface parameters. The operator must take care to configure the
new interface parameters while not impacting existing services. The
update procedure must apply as follows:
- Increase the PW capacity:
Step1: Negotiate the new interface parameters at the both PW
endpoints (ingress and egress PE) according to the procedure
described in this document.
Step2: Configure on CEs the new payload related to the new interface
parameters.
- Decrease the PW capacity:
Step1: Configure on CEs the new payload related to the new interface
parameters.
Step2: Negotiate the new interface parameters at the both PW
endpoints (PE1, PE2) according to the procedure described in this
document.
Jounay et al. Expires May 12, 2008 [Page 6]
Internet Draft Dynamic Update of PW parameters November 2007
6.2. PW Update Mechanism Reference Model
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| | | | | | | |
| CE1 |----------|............PW1.............|----------| CE2 |
| | | | | | | |
+-----+ | |==================| | +-----+
+----+ +----+
F1-> LLM (FEC1, L1, int. Par. [iP1,iP2]) <-F1
---------------------->
LLM (FEC1, L2, int. Par. [iP1,iP2])
<-----------------------
==========L2==========>
<=========L1===========
.
.
LLM (FEC1, L10, Update (iP, L), new int. Par. [iP1, iP2new])
-----------------------.
<=========L10==========
LLM (FEC1, L20, Update (iP, L), new int. Par. [iP1, iP2new])
<-----------------------
=========L20=========>
F2-> <-F2
Figure 4 PW Update Mechanism Reference Model
Figure 4 depicts the procedure to update PW interface parameters and
the PW label. Initially PE1, the ingress PE and egress PE has a PW
setup with two interface parameters iP1 and iP2 that defines how the
traffic received from the attached CEs must be forwarded over the PW.
CE1 and CE2 are sending traffic in a payload format F1.
Note that the mechanism reference provides the most challenging case
where interface parameters and PW label must be both updated. Some
use cases may require only to change the PW label or only to change
some PW interface parameters.
6.3. Control Plane
Referring to Figure 4, after the operator configures a new value
P2new for the interface parameter (iP2), the ingress PE sends an
"update" LLM message to indicate the new PW parameters to the egress
PE. The LLM message includes the PW Update sub-TLV that specifies
that the interface parameters and the Label must be updated. The LLM
message contains a new Label L10.
Jounay et al. Expires May 12, 2008 [Page 7]
Internet Draft Dynamic Update of PW parameters November 2007
Upon reception of the LLM message the egress PE checks the presence
of the PW Update sub-TLV. If the PW Update sub-TLV is included in the
LLM message, the egress PE carries on the process by responding to
the ingress PE with a new LMM message as described in [RFC4447] with
the new interface parameter iP2 and a new Label L20. The value of
this new interface parameter correspond to the one learnt from the
LLM message received from the ingress PE.
The interface parameters could be different and configured by the
operator at the ingress/egress PE for asymmetrical traffic.
6.4. Data Plane
Referring to Figure 4, after checking the presence of the PW Update
sub-TLV, the egress PE updates its PW-to-Label bindings with the
newly assigned Label L10. This Label is associated to the new format
defined by [iP1,iP2new] of the PW packet. The egress PE changes over
the traffic received from CE2 to the new format [iP1, iP2new] with
the new Label L10 thus deprecating the use of older format [iP1, iP2]
with label L2. This new Label assignment allows in-band detection.
Indeed, the ingress PE identifies the Label L10 and hence deduces the
associated format. This in-band detection is essential to allow it to
restitute correctly the traffic over its AC. That is particularly
required when the length field of the PW header is not sufficient to
correctly forward the traffic to the AC (e.g. CESoPSN PW).
The same procedure applies for the reverse direction.
Figure 4 corresponds to the "increase PW capacity" case since CE1 and
CE2 here send the new payload format F2 once the PW has been updated.
Note that the requirement to update the interface parameters without
any service disruption implies that each direction of the PW must
follow the procedure separately. This means that for some duration of
time during the update process, traffic from the egress PE to the
ingress PE may be in the new format, while traffic in the reverse
direction remains in the previous format.
7. Use Case: CESoPSN
The need to update interface parameters without service interruption
is particularly relevant for CESoPSN PWs. CESoPSN PWs carry TDM
traffic in a structure-aware fashion, with explicit specification of
the PW capacity (in multiples of 64 kbps). When using CESoPSN PWs,
there is an inherent trade-off between bandwidth consumption and
latency. It is thus very important to carefully match the capacity to
the actual payload.
Jounay et al. Expires May 12, 2008 [Page 8]
Internet Draft Dynamic Update of PW parameters November 2007
CESoPSN PWs are frequently used to encapsulate traffic in the mobile
backhauling architectures. When setting up such backhauling PWs the
needed capacity is known, but when growing the network the capacity
of particular PWs needs to grow without interrupting ongoing voice
services used by numerous customers.
7.1. Interface Parameters for CESoPSN PWs
This section refers to [PW TDM CTRL].
7.1.1. CEP/TDM Payload Bytes (0x04)
The interface parameter CEP/TDM Payload Bytes (0x04) (P) is defined
in [PW TDM CTRL] for a set of TDM PW types including SAToP. For
CESoPSN PWs, The specified value P MUST be an integer multiple factor
of N, where N is the number of timeslots in the attachment circuit.
7.1.2. CEP/TDM Bit-Rate (0x07)
For all kinds of structure-aware emulation, this parameter MUST be
set to N where N is the number of DS0 channels in the corresponding
attachment circuit that must be retrieved from the E1 frames and
must be transported over the CESoPSN PW.
Note that the number of frames to be encapsulated per PW packet is
derived from the value (P) and (N).
Packetization latency, number of timeslots and payload size are
linked by the following obvious relationship:
L = 8*N*D
where:
o D is packetization latency, milliseconds
o L is packet payload size, octets
o N is number of DS0 channels.
The payload corresponding to the value N are selected from the E1
frames, so as the CEP/TDM Payload Bytes (P) defined in [PW TDM CTRL]
corresponds to the value L multiplied by a number of E1 frames to be
encapsulated over the CESoPSN PW.
Jounay et al. Expires May 12, 2008 [Page 9]
Internet Draft Dynamic Update of PW parameters November 2007
7.2. CESoPSN Interface Parameters Update Mechanism Reference Model
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| | | | | | | |
| CE1 |----------|............PW1.............|----------| CE2 |
| | | | | | | |
+-----+ | |==================| | +-----+
+----+ +----+
N1-> LLM (FEC1, L1, int. Par. [N1, P1]) <-N1
---------------------->
LLM (FEC1, L2, int. Par. [N1, P1])
<-----------------------
==========L2==========>
<=========L1===========
.
.
LLM (FEC1, L10, Update (iP, L), new int. Par. [N2, P2])
-----------------------.
<=========L10==========
LLM (FEC1, L20, Update (iP, L), new int. Par. [N2, P2])
<-----------------------
=========L20=========>
N2-> <-N2
Figure 5 CESoPSN PW Update Mechanism Reference Model
Figure 5 depicts the procedure to update CESoPSN interface
parameters. Initially PE1, the ingress PE is assumed to setup a
CESoPSN PW with PE2, the egress PE with the two interface parameters
(N, P) defined in section 7.1.1, 7.1.2.
CE1 and CE2 are sending E1 frames with N1 timeslots payload.
The ingress PE picks the N1 timeslots from E1 frames to reach a
total payload of (P), encapsulates them in a PW packet and forwards
the PW packet to the ingress PE with Label L2.
7.3. Control Plane
Referring to Figure 5, after the operator configures the new
interface parameters (N2, P2), the ingress PE initiates a new LLM
message to indicate them to the egress PE. The LLM message includes
the PW Update sub-TLV which specifies the parameters to be updated
(interface parameter iP, PW Label L). The LLM message contains the
new interface paramters'value and the new Label L10.
Jounay et al. Expires May 12, 2008 [Page 10]
Internet Draft Dynamic Update of PW parameters November 2007
Upon reception of the LLM message the egress PE checks the presence
of the PW Update sub-TLV. Since the PW Update sub-TLV is included in
the LLM message, the egress PE carries on the process by responding
to the ingress PE with a new LMM message as described in [RFC4447]
with the new interface parameters and a new Label L20.
7.4. Data Plane
Referring to Figure 5, after checking the presence of the PW Update
sub-TLV, the egress PE updates its PW-to-Label bindings with the new
assigned Label L10. This Label is associated to the new format
defined by [N, P] of the PW packet. The egress PE switches the
traffic received from CE2 from PW1 in the previous format [N1, P1]
with the Label L1 to PW1 in the new format [N2, P2] with the new
Label L10. This new Label assignment allows in-band detection. Indeed
the ingress PE identifies the Label L10 and hence deduces the
associated format. This in-band detection is essential to allow it to
restitute correctly the traffic over its AC.
The same procedure applies for the reverse direction.
Figure 5 corresponds to the "increase PW capacity" case since CE1 and
CE2 here send the new payload (N2 timeslots payload per E1 frames)
once the PW has been updated.
Note that the procedure assumes that some empty payload is
encapsulated per PW packet between the both steps.
8. MS-PW Applicability
The PW update mechanism applies in an MS-PW environment as described
in [MS-PW ARCH].
The S-PEs must accept the new assigned Label, so must also be
capable to interpret the PW Update sub-TLV. The S-PEs must initiate
new LLM messages to the next hop with the new interface parameters
received from the ingress T-PE. These messages must contain a new PW
Label, so must also include the PW Update sub-TLV.
This section will be completed with more detail in a future version.
9. Pseudowire Update Backward Compatibility
TBD: in this draft a new capability bit, following procedures
defined in draft-thomas-mpls-ldp-capabilities-01.txt
With regards to Figure 4, since the ingress PE initiates the LLM
message, it MUST specify the PW Update sub-TLV without any Update
Code in the initial message in order to negotiate it with the egress
PE.
Jounay et al. Expires May 12, 2008 [Page 11]
Internet Draft Dynamic Update of PW parameters November 2007
When the egress PE receives the LLM message from the ingress PE, if
it supports the PW Update sub-TLV, at turn it MUST include it in the
LLM message in response to the initial message.
If the egress PE does not support the PW Update sub-TLV, it will
silently discard the sub-TLV as the U bit is set and the F bit is
cleared and will continue to perform the PW setup by initiating a
LLM message to the ingress PE.
In that case the egress PE sends a LLM message to the ingress PE
without the PW Update sub-TLV. The absence of this sub-TLV informs
the ingress PE that the egress PE is not capable to deal with the PW
Update sub-TLV.
10. Security Considerations
This security considerations of RFC4447 apply here as well.
11. IANA Considerations
Most of the IANA assignments required by this draft are already
listed in [RFC4446].
11.1. LDP TLV Type
This document uses a new LDP TLV types; IANA already maintains a
registry of name "TLV TYPE NAME SPACE" defined by RFC 3036. The
following values are suggested for assignment:
Sub-TLV PW Update
11.2. LDP PW Update Codes
This document proposes the definition of two new LDP PW Update codes
corresponding to the interface parameters and to the PW label
change.
The following values are suggested for assignment:
Range/Value E Description Reference
------------- ----- ---------------------- ---------
12. Acknowledgments
This draft borrows from concepts developed by Himanshu Shah in an
earlier draft entitled "Dynamic Parameters Signaling for MPLS-based
Pseudowires".
Jounay et al. Expires May 12, 2008 [Page 12]
Internet Draft Dynamic Update of PW parameters November 2007
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC4234] Crocker, D. and Overell, P.(Editors), "Augmented BNF
for Syntax Specifications: ABNF", Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", April 2006
[RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen,
E., "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", April 2006
13.2. Informative References
[PW TDM CTRL] Stein, Y., Vainshtein, A., "Control Protocol
Extensions for Setup of TDM Pseudowires", Internet
Draft, draft-ietf-pwe3-tdm-control-extensi-04.txt,
March 2008
[MS-PW ARCH] Bocci, M., and Bryant, S.,T., "An Architecture for
Multi-Segment Pseudo Wire Emulation Edge-to-Edge",
Internet Draft, draft-ietf-pwe3-ms-pw-arch-03.txt,
October 2006
[PWE3 CESoPSN] Vainstein, A, and al., "Structure-aware TDM Circuit
Emulation Service over Packet Switched Network
(CESoPSN)", Internet Draft, draft-ietf-pwe3-cesopsn-
07, LC
Author's Addresses
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Jounay et al. Expires May 12, 2008 [Page 13]
Internet Draft Dynamic Update of PW parameters November 2007
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: philippe.niger@orange-ftgroup.com
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Email: yaakov_s@rad.com
Himanshu Shah
Ciena Corp
35 Nagog Park
Acton, MA 01720
USA
Email: hshah@ciena.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.
Jounay et al. Expires May 12, 2008 [Page 14]
Internet Draft Dynamic Update of PW parameters November 2007
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 (2007).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jounay et al. Expires May 12, 2008 [Page 15]