Network work group Mach Chen Internet Draft Huawei Technologies Co.,Ltd Expires: April 2007 October 12, 2006 Inter-AS PCE Path Sequence Autoexplore draft-chen-pce-interas-pce-sequence-autoexplore-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 This Internet-Draft will expire on April 12, 2007. Abstract In Inter-AS scenario, as usual, multiple Path Computation Elements (PCEs) will take part in path computation. [PCE-DISCO-OSPF], [PCE- DISCO-ISIS],PCE-DISCO-BGP] or some other means can be used to discover all underling PCEs, but there is lack of solutions to find out those PCEs and their sequence which are engaged in computing an end-to-end inter-AS TE LSP. This document proposes a solution to identify these PCEs and their sequence which can be used to compute a TE LSP across multiple ASes. Mach Expires April 12, 2007 [Page 1] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction..................................................3 2. General assumptions...........................................4 3. Procedure.....................................................4 3.1. PCEP extension...........................................4 3.1.1. PCE Path Sequence Explore Request(PCPSReq) message..5 3.1.2. PCE Path Sequence Explore Reply(PCPSRep) message....5 3.1.3. Extension to PCReq message..........................6 3.2. PCE Path Sequence Explore................................7 3.3. PCE Path Sequence Explore flows..........................10 4. Objects format................................................12 4.1. END-POINTS object........................................12 4.2. SVEC object..............................................12 4.3. RP object................................................12 4.4. RRO object...............................................13 4.5. PCPSO object.............................................13 5. Security Considerations.......................................13 6. IANA Considerations...........................................13 6.1. PCPS Messages............................................13 7. References....................................................14 7.1. Normative References.....................................14 7.2. Informative References...................................14 Author's Addresses...............................................15 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................16 Copyright Statement..............................................16 Acknowledgment...................................................16 Mach Expires April 12, 2007 [Page 2] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 1. Introduction +--------+ +--------+ +--------+ | AS1 | | AS2 | | AS5 | | | | | | | | +====+ | | | | +====+ | | | Ra | |-------| |-------| | Rb | | | +====+ | | | | +====+ | | +====+ | | +====+ | | +====+ | | |PCE1| | | |PCE2| | | |PCE5| | | +====+ | | +====+ | | +====+ | +--------+ +--------+ +--------+ \ / / \ / / \ / / \ / / +--------+ +--------+ | AS3 | | AS4 | | | | | | |-------| | | +====+ | | +====+ | | |PCE3| | | |PCE4| | | +====+ | | +====+ | +--------+ +--------+ Figure 1: Inter-AS TE and multiple PCE scenario Multiple Protocol Label Switching (MPLS) Inter-AS Traffic Engineering as a key requirement has been stated in [INERAS-TE-REG], and Path Computation Element (PCE) has the ability to compute a TE LSP spanning multiple ASes. These ASes MAY be under one Service Provider(SP) administration or the administration of different SPs. [PCE-ARCH] has defined several models which can be used to satisfy different scenarios, one of them is "multiple PCE path computation" where multiple PCEs cooperate in computing a TE LSP across multiple domains. [PCE-DISCO-OSPF], [PCE-DISCO-ISIS] and [PCE-DISCO-BGP] has proposed some mechanisms to discover all underling PCEs automatically, but it is not enough to know this information only. Consider that we want to compute a TE LSP spanning multiple ASes and each AS has its own PCE responsible for path computation. As illustrated above in Figure 1, there are five ASes and five PCEs. We want to set up an end-to-end TE LSP from Ra to Rb. Obviously, there are several possible paths we MAY get, such as AS1->AS2->AS5, AS1->AS3-AS4->AS5, etc. According to existing PCE discovery mechanisms we only know that a specific PCE belongs to an AS and the PCE has some special capabilities. But we SHOULD also know which PCEs are engaged to compute such an end-to-end Mach Expires April 12, 2007 [Page 3] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 path and where is the next PCE when we need to send a PCE Path Request message. Otherwise, we will fail to compute such a end-to-end path. So, in order to perform path computation in such scenario, we need to find out those PCEs which are engaged in computing a specific TE LSP, and the sequence of those PCEs. As pointed out in [BPRC], before sending path computation request to the next PCE, we need to know where the next PCE is. Static configuration is an alternative method, but it may not be desirable in some cases. Therefore, it is desirable to find a way that can explore those underling PCEs and their sequence for a specific TE LSP dynamically. This document proposes a method which could easily explore those underling PCEs and their sequence for a specific end-to-end TE LSP automatically. The main idea is that a PCE uses the BGP AS_PATH attribute to find out those PCEs and track their sequence. 2. General assumptions In the rest of this document, there are some assumptions as follows: - All the underling PCEs can be discovered by [PCE-DISCO-OSPF], [PCE-DISCO-ISIS], [PCE-DISCO-BGP] or some other means (which is outside the scope of this document), and each PCE is identified with the AS which it belongs to. - As stated in [INTER-AS-PCE] each Inter-AS PCE is assumed to run BGP protocol (In fact, an Inter-AS PCE only needs to receive routing updates and almost doesn't send any updates if it just is a path computation engine. So, running BGP in an Inter-AS PCE is not a problem.), so each Inter-AS PCE has full routing information. - Each AS MAY have multiple PCEs, but for a specific TE LSP computation we can make a decision according to the capability of the PCE which one is the best(how to choose the best PCE is outside the scope of this document). 3. Procedure 3.1. PCEP extension In order to explore those PCEs and their sequence for a specific TE LSP, in this document we define two new PCEP messages, namely PCE Path Sequence Explore Request (PCPSReq) message and PCE Path Sequence Explore Reply (PCPSRep) message. At the same time, we need to do some extensions to PCReq message. Mach Expires April 12, 2007 [Page 4] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 3.1.1. PCE Path Sequence Explore Request(PCPSReq) message A PCE Path Sequence Explore Request message (also referred to as a PCPSReq message) is a message sent by a PCE to other PCEs(also referred to as helper PCE) to explore the PCE Path Sequence (also referred to as PCPS) for a specific TE LSP computation. The Message- Type field of the PCEP common header for the PCPSReq message is set to . A PCPSReq message MUST contain two objects: the END-POINTS object and the RP object. Other objects are optional. The format of a PCPSReq message is as follows: ::= [] Where: ::=[] ::=[] ::= [] [] The SVEC, RP, END-POINTS, and RRO objects are defined in Section 4. 3.1.2. PCE Path Sequence Explore Reply(PCPSRep) message A PCE Path Sequence Explore Reply message (also referred to as a PCPSReq message) is a message sent by a PCE to a requesting PCE in response to a previously received PCPSReq message. The Message-Type field of the PCEP common header for the PCPSRep message is set to . A PCPSRep message MUST contain two objects: the RP object and RRO object. Other objects are optional. The format of PCPSRep message is as follows: ::= [] where: Mach Expires April 12, 2007 [Page 5] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 ::=[] ::=[] ::= [] [] ::=[] ::= The SVEC, RP, and RRO objects are defined in Section 4. 3.1.3. Extension to PCReq message In order to finish the computation of a TE LSP spanning multiple ASes, a PCReq message SHOULD carry a new object termed PCE Path Sequence Object (PCPSO). The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] Mach Expires April 12, 2007 [Page 6] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 ::= [] [] [] [] [] [] [] [] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, and IRO objects are defined in [PCEP] Section 7. The PCPSO object is defined in Section 4. 3.2. PCE Path Sequence Explore In section 2, we have made an assumption that each PCE needs to run BGP protocol, so each PCE has full routing information. When a PCE receives a Path Computation Request (PCReq) message from a PCC, it MUST make a decision whether it could finish the path computation by itself or need the help of other PCEs (the destination node is in anther AS or some other factors, the detail procedure is outside the scope of this document). If it is latter, the PCE MUST find out those PCEs (also referred to as helper PCE) and the PCPS of those PCES. The detail procedure is as follows: First of all, according to the destination address where a specific TE LSP will reach, the PCE (also referred to as an original PCE) finds out all routes which can reach the destination by looking up its local BGP rib. These routes not only include the best route, but also non best routes. Then, the original PCE iterates these BGP routes and checks their AS_PATH attribute. If the first segment of AS_PATH of type is AS_SEQUENCE, the last element of the AS_SEQUENCE is the AS (referred to as next AS) where the BGP route traversed lastly. According to this AS number, it's easy to find out the PCE identified by this AS number from its local PCE database which contains all underling PCE infomation collected by [PCE-DISCO-OSPF], [PCE-DISCO-ISIS], [PCE-DISCO-BGP] or some other means. There MAY be multiple routes which could reach the destination node, so multiple PCEs MAY be found out. After finding these helper PCEs, the original PCE sends a PCPSReq message to these helper PCEs respectively. When a helper PCE receives a PCPSReq message, the helper PCE checks the PCPSReq message and extracts the address info of destination node from END-POINTS object, according the destination address the helper PCE continues doing the same operation as the original PCE does. That Mach Expires April 12, 2007 [Page 7] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 is looking up its local BGP rib to find out specific BGP routes which can reach the destination node, iterating these BGP routes to find out specific next AS numbers and according to these next AS numbers to find out relative helper PCEs from their local PCE databases. After that, the helper PCE will send a PCPSReq message to its helper PCEs respectively. If a helper PCE finds that the routes in its local BGP rib doesn't contain any AS_PATH information, it concludes that this helper PCE itself is the final PCE we want to track. Then the final PCE sends a PCPSRep message with RRO object containing its PCE address to the requesting PCE in response to a previously received PCPSReq message. When a PCE (referred to as intermediate PCE) receives a PCPSRep message, after adding its PCE address into the RRO object, the intermediate PCE relays the PCPSRep to the requesting PCE in response to a previously received PCPSReq message. All the intermediate PCEs will do the same operation until the PCPSRep message relayed to the original PCE. On receiving all PCPSRep messages, the original PCE can get all underling PCE Path Sequences (PCPSes) from the RRO object in each PCPSRep message. If the received PCPSReq message has errors, a PCE MUST reply with PCErr message immediately. The PCErr messages are defined in [PCEP] section 6.7. Here we give an example to detail the procedure of PCPS exploring. As illustrated above in Figure 1, there are five ASes (from AS1 to AS5) and every AS has its own PCE. Let's consider this scenario, says that Ra wants to establish a TE LSP to Rb, Ra as Path Computation Client(PCC) sends a path computation request to its default PCE, namely PCE1(how to choose the default PCE is outside the scope of this document). As usual, consider the confidentiality and administration requirements, PCE1 MAY hasn't the fully TE information about other ASes. So PCE1 can't compute such a TE LSP spanning multiple ASes only by itself, it needs to cooperate with other PCEs. When PCE1 receives the PCReq from its PCC Ra, PCE1 is the original PCE. At first, PCE1 looks up its local BGP rib according to Rb's IP address. Suppose that PCE1 finds out two BGP routes, one is from AS2, the other is from AS3. According to these BGP routes' AS_PATH attribute, PCE1 can find out two helper PCEs relative to AS2 and AS3 respectively. One is PCE2, and the other is PCE3. Then, PCE1 sends a PCPSReq message to PCE2 and PCE3 respectively. When PCE2 or PCE3 receives the PCPSReq message, they will check if the request message is valid or not. If the message has errors, they Mach Expires April 12, 2007 [Page 8] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 will send a PCErr message to PCE1 immediately. If the message is valid, they will extract Rb's IP address from the PCPSReq message and continue to do the same operation as PCE1 does. That is PCE2 will try to find out its helper PCEs(MAY be PCE3 and PCE5) and PCE3 will try to find out its helper PCEs(MAY be PCE2 and PCE4) too. The PCE2 will send a PCPSReq message to PCE3 and PCE5 respectively, and PCE3 will send a PCPSReq message to PCE2 and PCE4 respectively. When all PCPSReq messages reach PCE5, PCE5 will find out the final PCE is itself. So PCE5 as the final PCE sends a PCPSRep message with RRO object containing its IP address to every requesting PCE in response to every previously received PCPSReq message. After adding their IP address into RRO objects, PCE2, PCE3 and PCE4 as the intermediate PCE will relay these PCPSReq messages till to the original PCE, namely PCE1. Finally, there MAY be several PCPSes found, they are probably as follows: PCE1-PCE2 PCE5 PCE1-PCE3 PCE4 PCE5 PCE1-PCE3 PCE2-PCE5 PCE1-PCE2 PCE3-PCE4-PCE5 When PCE1 get these PCPSes info, PCE1 can choose one or multiple PCPSes (MAY be based on the best shortest path, how to choose is outside the scope of this document) to perform path computation for the TE LSP from Ra to Rb. At the same time, when PCE1 sends a PCReq message to its helper PCEs, it SHOULD carry a PCPSO object and before these helper PCEs send or relay the PCReq message to their helper PCEs, they SHOULD omit themselves from the PCPSO object. The PCReq message will be sent along with the chosen PCPS to a final PCE, so we have enough information to finish an end-to-end Inter-AS path computation. PCPSO object is defined in Section 4.5. Mach Expires April 12, 2007 [Page 9] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 3.3. PCE Path Sequence Explore flows +-+-+-+ +-+-+-+ +-+-+-+ |O-PCE| |I-PCE| ...... |F-PCE| +-+-+-+ +-+-+-+ +-+-+-+ | | | |PCPSReq message->| | | |1) PCPSReq received | | | | | |2) Not the final PCE | | | | | |3) Send a PCPSReq to next | | |I-PCE based on AS-PATH | | | |1) PCPSReq received | |----- PCPSReq message---->| | | |2) Is the final PCE | | | | | |3) Positive reply | |<---- PCPSRep message ----|send to a requesting | | (Positive reply) |I-PCE(with its IP | | |address) | |1) PCPSRep received | | | | | |2) Relay positive reply to| | |a requesting O-PCE(adding | | |its IP address into the | | |reply message before send | | | | |<-PCPSRep message| | | (Positive reply)| | Figure 2: Successful Path Sequence Explore Mach Expires April 12, 2007 [Page 10] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 +-+-+-+ +-+-+-+ +-+-+-+ |O-PCE| |I-PCE| ...... |F-PCE| +-+-+-+ +-+-+-+ +-+-+-+ | | | |PCPSReq message->| | | |1) PCPSReq received | | | | | |2) Some errors | | | | | |3) Negative reply sent to | | |O-PCE | |<-PCPSRep message| |1) PCPSReq received | (Negetive reply)|----- PCPSReq message---->| | | |2) Some errors | | | | | |3) Negative reply | | |send to a requesting | |<---- PCPSRep message ----|I-PCE | | (Negetive reply) | | | | | |1) PCPSRep received | | | | | |2) Relay Negative reply to| | |a requesting O-PCE | | | | | | | |<-PCPSRep message| | | (Negative reply)| | Figure 3: Unsuccessful Path Sequence Explore The above figures are the general description about PCE Path exploring. O-PCE: means original PCE. I-PCE: means intermediate PCE. F-PCE: means final PCE. F-PCE and I-PCEs are helper PCEs of O-PCE as described in Section 3.2. Positive and Negative has same means as described in Section 5.2.3 of [PCEP]. Mach Expires April 12, 2007 [Page 11] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 4. Objects format In this document, it just defines a new object named PCPSO object. The other objects have been defined in [PCEP] section 7, and here we only do a little bit extension to some of them. 4.1. END-POINTS object The contents of this object are identical in encoding to the contents of the END-POINTS Object defined in [PCEP]. 4.2. SVEC object The contents of this object are identical in encoding to the contents of the SVEC Object defined in [PCEP]. 4.3. RP object RP object has been defined in [PCEP] section 7, the format of the RP object body 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |C|Q|R|N|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: RP object body format In this document, we add 3 new bits to flag field of RP object. They are defined as follows: C (Synchronization, 1 bit): when set, a PCE receives a PCPSReq message, it can't reply to the requesting PCE until it received the specific PCPSRep message from its helper PCE. But when a PCE receives a PCPSReq message with errors, it will reply with PCErr message to the requesting PCE immediately. Default C bit is set. Q (PCPSReq carry RRO or not, 1 bit): when set, PCPSReq MUST carry RRO object, the original PCE and helper PCE will add their IP address Mach Expires April 12, 2007 [Page 12] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 into the RRO object before sending a PCPSReq message to their helper or final PCE. So when a PCPSReq message reaches to a final PCE, the final PCE can get the PCPS from RRO object in PCPSReq message. Therefore, the final PCE can send this info direct to original PCE without the helping of intermediate PCEs. This is an alternative method to get the PCPS information. Default Q bit is cleared. R (PCPSRep carry RRO or not, 1 bit): when set, PCPSRep MUST carry RRO object, the final PCE and intermediate PCE will add their IP address into the RRO object before sending a PCPSRep message to a requesting PCE. Default R bit is set. 4.4. RRO object The RRO object is used to record PCE Path Seqeunce (PCPS). The contents of this object are identical in encoding to the contents of the Route Record Object defined in [RFC3209], [RFC3473] and [RFC3477]. That is, the object is constructed from a series of sub- objects. 4.5. PCPSO object The PCPSO object is optional and can be used to carry PCPS info which can be used to direct where a PCE sends a PCReq message to. The contents of this object are identical in encoding to the contents of the Explicit Route Object defined in [RFC3209], [RFC3473] and [RFC3477]. That is, the object is constructed from a series of sub- objects. Each sub-object expresses a PCE. 5. Security Considerations This extension to PCE does not change the underlying security issues. 6. IANA Considerations 6.1. PCPS Messages Each PCPS message has a Message-Type. Value Meaning 8 PCE Path Sequence Explore Request. 9 PCE Path Sequence Explore Reply. Mach Expires April 12, 2007 [Page 13] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 7. References 7.1. Normative References [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [PCE-ARCH] A. Farrel, J.-P. Vasseur, J. Ash, " A Path Computation Element (PCE)-Based Architecture ", RFC 4655, August 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 7.2. Informative References [BRPC] Vasseur,J., Zhang,R., Bitar, N., Le Roux,JL., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths" draft-vasseur-pce-brpc-01 ( work in progress )June 2006 [PCE-DISCO-OSPF] Le Roux,JL., Vasseur,J., Ikejiri,Y., and Zhang,R., "OSPF protocol extensions for Path Computation Element (PCE) Discovery" draft-ietf-pce-disco-proto-ospf-00 (work in progress) Sep 2006. [PCE-DISCO-ISIS] Le Roux,JL., Vasseur,J., Ikejiri,Y., and Zhang,R., "ISIS protocol extensions for Path Computation Element (PCE) Discovery" draft-ietf-pce-disco-proto-isis-00 (work in progress) Sep 2006. [PCE-DISCO-BGP] Vijayanand,C., and Bhattacharya,S., "BGP Protocol extensions for PCE Discovery across Autonomous systems" draft-vijay-somen-pce-disco-proto-bgp-00.txt June 2006. [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering Requirements", RFC4216, November 2005. Mach Expires April 12, 2007 [Page 14] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 [CCAMP-INTER-DOMAIN-TE] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic Engineering - RSVP-TE extensions",draft-ietf- ccamp-inter-domain-rsvp-te-03 (work in progress), March 2006. [PCE-COMM-GEN-REQ] Roux,J. and J. Ash, "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen- reqs-06 (work in progress), May 2006. [PCE-DISCO-REQ] Roux,J., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-05 (work in progress), June 2006. [INTER-AS-PCE] Bitar,N., Zhang,R., Kumaki,K., "Inter-AS PCE Requirements", draft-bitar-zhang-interas-pce-req-00.txt (work in progress), October 2005. Author's Addresses Mach Chen Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing P.R. China 100085 Email: mach@huawei.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. Mach Expires April 12, 2007 [Page 15] Internet-Draft Inter-AS PCE Sequence Autoexplore October 2006 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 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 Internet Society (2006). 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. Mach Expires April 12, 2007 [Page 16]