draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 Network Working Group Internet Draft Diego Caviglia (Ericsson) Dino Bramanti (Ericsson) Dan Li (Huawei) Document: draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 Proposed Status: Updates RFC 3473 Expires: July 2007 February 2007 GRSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS enabled Transport Network 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 July 19, 2007. Copyright Notice Caviglia et al. Expires - August 2007 [Page 1] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 Copyright (C) The IETF Trust (2007). Abstract In a transport network scenario, where Data Plane connections controlled either by GMPLS (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a valuable option. This applies especially when a GMPLS based Control Plane is first introduced into an existing network and there may be the need, from a Carrier point of view, to pass under GMPLS control existing connections already set up over Data Plane. In other terms, such operation could be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo provides a minor extension to GRSVP-TE signaling protocol, within GMPLS architecture, to enable such transfer of ownership and describes the proposed procedures. 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 [i]. Table of Contents 1. Introduction...................................................3 2. Motivation.....................................................3 3. Overview Of Proposed GRSVP-TE Based Solution...................3 4. LSP Control Handover Procedure Between Management And Control Planes............................................................4 4.1 MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane.........................................5 4.2 MP to CP Handover Procedure Failure Handling...............8 4.3 CP to MP handover - LSP Ownership Transfer From Control Plane To Management Plane........................................8 4.4 CP to MP Handover Procedure Failure Handling...............9 5. Alternative Way Of Retrieving Information Needed For MP To CP Handover..........................................................9 6. RSVP Message Formats..........................................10 6.1 Objects Modification......................................11 7. Security Considerations.......................................11 8. IANA Consideration............................................11 Caviglia et al. Expires - August 2007 [Page 2] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 9. Normative References..........................................11 10. Informative References.......................................12 11. Acknowledgments..............................................12 12. Author's Addresses...........................................12 1. Introduction In a typical, traditional transport network scenario, Data Plane connections between two endpoints are controlled basically by means of a Network Management System (NMS) operating within Management Plane (MP). NMS/MP is the owner of such transport connections, being responsible of their set up, tear down and maintenance. The adoption of a GMPLS Control Plane over networks that are already in service - controlled by NMS at Management Plane level - introduces the need for a procedure able to coordinate a control handover of a generic data plane connection from MP to CP. In addition, the control handover in the opposite direction, from CP to MP should be possible as well. 2. Motivation The main motivation behind this work is the definition of a simple and very low impacting procedure that satisfies the requirements defined in [8]. Such procedure is aimed at giving the transport network operators the chance to convert existing LSP provisioned as PC by NMS to SPC without disrupting user traffic flowing on it. Conversion from PC to SPC (i.e. when existing data plane connection ownership and control is passed from MP to CP) has been proposed as mandatory requirement, while the opposite operation, SPC to SC conversion, has been considered as a nice-to-have feature that can be seen as a back-out option. For more details on requirements and motivations please refer to [8]. 3. Overview Of Proposed GRSVP-TE Based Solution Proposed procedure requires, as the only tiny modification to standard GRSVP-TE signalling, the utilization of a newly introduced flag, here named Handover flag, in the Administrative Status Object (RFC 3471[4] and RFC 3473 [5]). The point is that standard GRSVP-TE signaling flow can be used to inform nodes about the ownership handover request regarding one LSP that is already in place on their data plane, where such flow has to be flagged in order to discriminate it from normal LSP setup/release procedure. When a LSP owned by Management Plane (i.e. a PC) has to be handed over to Control Plane (i.e. converted into a SPC), a signaling set-up with HANDOVER flag set has to be sent from ingress node. Caviglia et al. Expires - August 2007 [Page 3] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 For the opposite procedure (when a LSP owned and controlled by Control Plane has to be handed over to Management Plane, i.e. SPC to PC conversion - or back out procedure for previous case) a signaling tear-down with HANDOVER flag set has to be sent from ingress or egress node, following the same procedure of a normal tear-down, from which is recognizable again by reading flag value. So, basically the HANDOVER flag is introduced and exploited to tell apart a normal set-up (or tear-down) procedure - that has to trigger an action on data plane state at each addressed node along the path as usual - from the LSP ownership handover procedure that MUST leave untouched data plane state. This is in some way similar as an approach to the Restart Procedure, (Section 4.3 RFC 3473 [5]), in the sense that the status of the physical resources at Data Plane has to stay unmodified but the associated information allowing its control has to be transferred. The modification proposed in this document refers only to Administrative Status object, that is, the message flow is left unmodified for both set-up and deletion. It is worth stressing that, when the LSP over data plane is adopted either by CP or MP, i.e. at the end of signaling with Handover flag set, normal CP procedures or MP procedures have to take their place as usual when needed. This means that a LSP formerly owned by MP, signalled within CP with Handover flag set (i.e. handed over to CP) can be controlled by usual relevant Control Plane signaling flows (i.e. with Handover flag not set). The same applies when considering the handover of a LSP from CP to MP when, at the end of procedure, the LSP belongs to Management Plane and can be fully controlled by NMS. In other words, after the LSP handover procedures have taken place, the LSP is not different from the other LSP owned by handover destination entity and it has to be treated with usual rules for that entity. Following paragraphs give detailed description of proposed "MP to CP handover" and "CP to MP handover" procedure, focussing based on Handover flag usage. Handover of a bidirectional LSP is assumed. The case of unidirectional LSP can be easily derived from that. 4. LSP Control Handover Procedure Between Management And Control Planes The procedure described below implies that Resv Confirm message in LSP setup signaling flow SHOULD be supported in order to manage at best LSP Ownership Handover procedure between Control and Management planes. If Resv Confirm is not present in message set used for LSP setup, the procedure below is still applicable using the simple Caviglia et al. Expires - August 2007 [Page 4] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 Path/Resv sequence (with handover flag set as detailed in the following). In such a case, handover related operations that are described as triggered by reception of Resv Confirm, MUST be executed at the reception of Resv message. 4.1 MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane Let's consider the case of a Data Plane connection between two nodes acting as ingress and egress for a LSP. Let's assume that Management Plane has the ownership and control of the LSP and that we want to hand it over to Control Plane. At the ingress node NMS initiates the transfer of LSP related information residing within Management Plane to GRSVP-TE records within Control Plane. We assume that this happens under operator or management application control and in particular that: - Control requests are sent to the ingress LSR by the MP - The MP has some way of knowing when the CP has completed its task or has failed. Ingress node collects from MP all the LSP related information needed at Control Plane level. The way this operation is done and where such information is collected within MP is outside the scope of this memo. A relevant part of such information is represented by the LSP path, which has to be handed over to CP to be used by signaling entity to fill the Explicit Route Object (ERO) during setup. In order to support the MP to CP handover of LSP, the ERO object in the Path message MUST be filled with all the LSP relevant information down to the Label level. That can be done by means of the object and procedures defined in [5]. The precise filling of the ERO object is needed as we are assuming that the LSP already exists in data plane and that every signaling relevant info about it is available and accessible to MP in terms of required LSP parameters to build a GRSVP-TE PATH message. After the collection of all the LSP related information, the ingress node issues a GRSVP-TE PATH message including the Administrative Status Object with HANDOVER flag set. Upon reception of such GRSVP-TE PATH, a node MUST be able to understand that a MP to CP handover procedure is in progress by reading the Handover flag. Either the ingress node of the LSP (upon request from MP) and intermediate and egress nodes (when receiving a Path message containing an Administrative Status object with the Handover flag set) is informed about the fact that a LSP adoption procedure is requested or ongoing. The node assumes that a Data Plane resource related to the info carried in Path Message is already allocated and Caviglia et al. Expires - August 2007 [Page 5] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 in place. The node SHOULD check however the consistence of the actual Data Plane status of such resource: - If the check goes OK, then a GRSVP-TE record for the LSP is created associating it to the corresponding Data Plane state. The node accepts all the LSP information carried in PATH (if the node is not ingress of the LSP, otherwise the information is sent from relevant MP entity) and stores it in Path State Block. After that, the procedure goes on as described below. - If the check goes NOT OK, that is actual Data Plane state for the indicated resource is different from the one indicated in the Path message, then: o A PathErr with Path State Removed flag set should be generated o GMPLS Control Plane state information about it is not accepted by the handover destination entity In both cases, no operation is done over Data Plane. In case of positive check, no change is required at that level since the connection is already set up and in service. In case of negative check, a mismatch or some other error has occurred and no LSP control handover is possible. The procedure rolls back and information transfer process from MP to CP at ingress node of the LSP has to be fixed and reinitiated. A node participating in a MP to CP handover procedure MUST in fact keep track of the special 'handover' condition of the LSP involved, by retaining handover flag status within GRSVP- TE records. This is important because during handover procedure no other Data Plane, Control Plane or Management Plane action has to be taken on the LSP outside the control of the procedure itself. Such special state regarding the involved LSP has to be retained until the procedure itself has correctly ended. After propagating handover Path, a node MUST wait for a Resv message including Administrative Status Object with handover flag set. After receiving it, the actual migration of LSP information is complete. However, Handover flag is cleared in Path/Resv state block of the involved LSP, only by reception of ResvConfirm message (or Resv message, if ResvConfirm is not supported). After the flag is cleared, the LSP is left completely under control of GRSVP- TE within Control Plane. This means that any memory about the former MP ownership of the LSP is lost. The following example covers all possible MP to CP Handover scenarios, either in case of success or failure. In the example we assume that Data Plane connection, whose control and control information has to be handed over from MP to CP, is TDM based (either SDH or SONET). A more generic case, where the Data Plane resource Caviglia et al. Expires - August 2007 [Page 6] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 making up the LSP is not tied to a specific technology, can easily be derived from this one. The table refers to possible cases when a node at CP level has received LSP information provided by MP and verifies if handover is feasible. Let's consider a LSP over the network, connecting a ingress node I with an egress node E. Let's call timeslot A and B the Data Plane resources referred by control information involved in Handover in a given node traversed by the LSP. This means that Handover flagged signaling refers to A-B cross-connection over Data Plane. The ingress node initiates the procedure upon request from Management Plane. The way LSP related information is passed from MP to ingress node is outside the scope of this procedure description. Intermediates nodes and egress node receive the request for LSP adoption and the information needed for the operation from Handover flagged GRSVP-TE signaling. The symbol <----> in table below indicates that the two Timeslots involved in Data Plane cross-connection are actually cross-connected over Data Plane, hence Data Plane state corresponds to the indication provided by LSP data held by MP and in the process of being handed over to CP. |Actual Data|Control Plane |Management Plane|Data Plane |Plane State|LSP data record|LSP data record |Resources check Case 1| A<---->B |No info yet |MP expects A-B |OK to MP to CP | | | |LSP handover Case 2| A<---->C |No info yet |MP expects A-B |NOT OK for MP to | | | |CP LSP handover Case 1: - LSP info from Management Plane to be used for LSP control hand over to GRSVP-TE matches Data Plane state in terms of involved resources - LSP data record is not owned yet by Control Plane, hence LSP control is still up to MP - Checks are OK, so GRSVP-TE state (related to involved LSP) is associated to Data Plane state after Handover flagged signaling flow (Path/Resv/Resv Confirm with Handover flag set) has ended. - At the end of signaling the LSP is completely under CP control. - No actions are taken in the Data Plane. Case 2: - LSP info from Management Plane to be used for LSP control hand over to GRSVP-TE doesn't match Data Plane state in terms of involved resources. - Control Plane does not own LSP data record yet; hence LSP control is still up to MP. Caviglia et al. Expires - August 2007 [Page 7] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 - Checks are NOT OK. A-B connection is not actually present over Data Plane and indicated resources are used within other context (A is x-connected to C). - GRSVP-TE state (related to involved LSP) is not associated to the cross connection after Handover flagged Path message. - A PathErr with Path State Removed flag set MUST be sent Upstream. - LSP ownership remains completely under MP control. Handover has failed. - No actions are taken in the Data Plane. 4.2 MP to CP Handover Procedure Failure Handling When a mismatch is detected between LSP information owned by MP (and going to be handed over to CP) and the actual Data Plane state corresponding to that LSP, actions have to be taken to roll back the LSP ownership handover correctly. If such mismatch is detected at LSP ingress node, the issue has to be resolved directly between ingress node and MP designed entity and this lies outside the scope of this memo. No Control plane signaling is involved yet at this stage. If the mismatch is detected at intermediate or egress nodes, when the LSP control information arrives at the node via handover flagged Path message, the node MUST reject it by issuing PathErr with Path State Removed towards the ingress node. In such a way the procedure is interrupted at that node, upstream nodes are informed and no changes are done over control and Data Plane. When a node receives PathErr with Path State Removed referred to a LSP, whose data record at CP has handover flag set (being in 'handover state'), it MUST clear such LSP data record and propagate the PathErr message upstream. No Data Plane actions have to be taken in this case as well. The same applies to PathTear message. 4.3 CP to MP handover - LSP Ownership Transfer From Control Plane To Management Plane Let's now consider the case of LSP Ownership Transfer From Control Plane To Management Plane. The scenario is still a Data Plane connection between two nodes acting as ingress and egress for a LSP. But let's assume in this case that Control Plane has the ownership and control of the LSP and that we want to hand it over to Management Plane. This means that at the end of such procedure, the Data Plane state related to that connection is still untouched, but the LSP related information record is no more owned by GRSVP-TE over Control Plane. In other words, after LSP ownership transfer from CP to MP, the LSP is no more under control of GRSVP-TE, which is no more able to "see" the LSP itself. This Section covers the procedure needed to manage Caviglia et al. Expires - August 2007 [Page 8] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 this procedure as a dual, opposite procedure respect to the one described in previous section. The procedure is performed at a signaling level as described in Section 7.2.1 of the RFC 3473 [5]. At LSP ingress node, relevant MP entity requests the ownership of the LSP, How this is done is outside the scope of memo. Ingress node and MP exchange the relevant information for this task and then propagates it over Control Plane by means of GRSVP-TE tear down signaling flow as detailed below. Ingress node MUST send out a Path Down message, with Handover and Reflect bits in Admin Status set. No action is taken over Data Plane and Control Plane keeps track of special handover state the LSP is in. Transit and Egress nodes, upon reception of such handover Path Down, propagate it without any Data Plane action, retaining the handover state information associated to the LSP. After that, every node waits until the Handover bit is received back in the Resv. Then a PathTear is issued and the whole LSP information record is cleared from GRSVP- TE data structures. In other words, a normal LSP tear down signaling is exchanged between nodes traversed by the LSP, but handover flag set in Path Down message indicates that no Data Plane action has to correspond to Control Plane signaling. At the end of handover tear down signaling flow, the LSP is released from Control Plane point of view, but its Data Plane state is still unmodified and it is now owned and controllable by MP. 4.4 CP to MP Handover Procedure Failure Handling Failures during CP to MP handover procedure MUST be managed at signaling level as in normal LSP tear down procedure. The only difference is the handover flag set in Administrative Status Object inside Path Down message which MUST be read by receiving node and imposes that no action has to be made over Data Plane resource whose corresponding Control Plane record is involved in handover procedure. 5. Alternative Way Of Retrieving Information Needed For MP To CP Handover An alternative way of getting the LSP related information required for the MP to CP handover is also proposed in this draft. The rationale behind this way is that only a minimal set of information is handed over from MP to CP at LSPs Ingress node. Instead of collecting within MP all the LSP relevant information down to the Label level, formatting it to an ERO and passing it to CP, as in previously described solution, it is possible to start with a minimum amount of information. At the ingress node, the information needed to Caviglia et al. Expires - August 2007 [Page 9] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 specify the LSP is the outgoing interface ID, upstream label and downstream label of this interface and the incoming interface ID of egress node. The remaining information about an existing LSP can then be collected hop by hop, as the signalling is going on, by looking up the cross-connection table in data plane at each node along the LSP path. Starting from the information available at ingress TNE about the outgoing interface ID of that ingress node, the incoming interface ID of next hop can be found by looking up the link resource table/database in TNE itself. Following the similarity existing between the MP to CP handover procedure and the Restart Procedure, the Recovery Label Object MUST be used to carry the downstream label and the Upstream Label Object MUST be used to carry the upstream label to the next node. The Path message is hence built with the Recovery Label Object (RFC 3473[5]) and the Upstream Label Object (RFC 3473[5]), where the upstream label and downstream label of ingress outgoing interface of the LSP are included in these two objects. In addition to above mentioned objects, the Path message MUST include the Administrative Status Object with HANDOVER flag set, as already defined in previous chapter for the detailed ERO based way of proceeding. Such handover Path is sent to the incoming interface of next hop. When this Path message reaches the second node along the LSP path, the information about incoming interface ID and the upstream and downstream labels of this interface is extracted from it and it is used to find next hop outgoing interface ID and the upstream/ downstream labels by looking up the data plane cross-connection table. After having determined in this way the parameters describing the LSPs next hop, the outgoing Path message to be sent is built replacing the Recovery Label Object and Upstream Label Object content with the looked-up values of upstream and downstream labels. Re-iterating this procedure for each transit node along the LSP path, it is possible to make the handover Path message reach the egress node, exactly following the LSP that is in place over data plane. The ERO MAY in this case be included in the Path message as an optional object, and MAY be filled with the LSP relevant information down to either the port level with interface ID or the Label level with upstream and downstream labels. The ERO can be used to check the consistence of resource in data plane down to the port level or label level at each intermediate node along the LSP path. 6. RSVP Message Formats This memo does not introduce any modification in RSVP messages. Caviglia et al. Expires - August 2007 [Page 10] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 6.1 Objects Modification This memo introduces a new flag into the Administrative Status object. The Admin_Status Object is defined in RFC 3473 [5]. This document uses the H-bit of the Admin_Status object. The bit is bit number (TBD by IANA). Handover signaling (H): 1 bit When set, indicates that a Handover procedure for the transfer of LSP ownership between Management and Control Planes is ongoing . 7. Security Considerations The procedures described in this document rely completely on GRSVP-TE messages and mechanism. The use of Handover Flag set in Admin Status Object basically informs the receiving entity that no operations are to be done over Data Plane as consequence of such special signaling flow. Using specially flagged signaling messages we want to limit the function of setup and tear down messages to Control Plane, making them not effective over related Data Plane resource usage. So, no additional or special issues are arisen by adopting this procedure, that aren't already brought up by the use of the same messages, without handover flag setting, for LSP control. For GRSVP-TE Security please refer to [3]. 8. IANA Consideration IANA has been asked to manage the bit allocations for the Administrative Status object [6]. This document requires the allocation of the Handover bit: the H-bit. IANA is requested to allocate a bit for this purpose. 9. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 Caviglia et al. Expires - August 2007 [Page 11] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 [4] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003 [5] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 10. Informative References [6] Zamfir, A., "Component Link Recording and Resource Control for GMPLS Link Bundles", draft-zamfir-explicit-resource-control-bundle- 03, February 2004 - work in progress. [7] L. Berger (Ed.) "GMPLS - Communication of Alarm Information", draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in progress. [8] D. Caviglia, D. Bramanti, D. Li "GMPLS Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", draft- caviglia-ccamp-pc-and-sc-reqs-04.txt, September 2006 11. Acknowledgments We wish to thank Adrian Farrel for his editorial assistance and precious advices to prepare this draft for publication. We also wish to thank Nicola Ciulli that contributed to initial stage of this draft. 12. Author's Addresses Diego Caviglia Ericsson Via A. Negrone 1/A Genova-Sestri Ponente, Italy Phone: +390106003738 Email: diego.caviglia@marconi.com Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa, Italy Email: dino.bramanti@marconi.com Dan Li Caviglia et al. Expires - August 2007 [Page 12] draft-caviglia-ccamp-pc-spc-grsvpte-ext-00 February 2007 Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Email: danli@huawei.com Tel: +86-755-28972910 Full 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. 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. Intellectual Property 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. Caviglia et al. Expires - August 2007 [Page 13]