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]