Sigtran X. Chen Internet-Draft H. Zhang Intended status: Informational X. Duan Expires: January 7, 2009 Y. Zhao China Mobile X. Li Alcatel Shanghai Bell July 6, 2008 The requirement and proposal of extenting M3UA signalling network route management draft-chen-sigtran-m3ua-extension-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 January 7, 2009. Chen, et al. Expires January 7, 2009 [Page 1] Internet-Draft extenting M3UA July 2008 Abstract RFC 4666 defines M3UA a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. M3UA is designed for SEP-(TDM)-SG-(IP)-IPSEP and IPSEP-(IP)-IPSEP applications, so the network level management function isn't required. But when M3UA is used in IP based signaling network, the network level management function needs to be extended. This document provides the proposals for extending M3UA signalling network route management. This document is consistent with RFC4666 in other sides. Table of Contents 1. The Overview of IP based signalling network . . . . . . . . . 3 2. The Corresponding M3UA configuration in IP based signalling network . . . . . . . . . . . . . . . . . . . . . . 5 3. The requirement of extending M3UA signalling network route management . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. The proposal of extending M3UA signalling network route management . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. The route management about Destination uavailable/available . . . . . . . . . . . . . . . . . . . 10 4.2. The route management about Destination user part unavailable/available . . . . . . . . . . . . . . . . . . 10 4.2.1. The route management description . . . . . . . . . . . 10 4.2.2. The extension for DUPU massage . . . . . . . . . . . . 11 4.3. The Corresponding signalling node operation . . . . . . . 13 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Chen, et al. Expires January 7, 2009 [Page 2] Internet-Draft extenting M3UA July 2008 1. The Overview of IP based signalling network I The world trend of IP bearer for signalling makes SIGTRAN standard widely used in signalling network, and also makes IP based signalling network possible. An IP based SS7 signalling network using M3UA/SCTP/IP as transport layer has been defined by 3GPP, SEPs such as HLR, MSC can communicate with each other directly by accessing to this IP based signalling network. When deploying a large scale signalling network based on IP, it is better to separate the network into several sections, keep the number of SEPs in each section in an appropriate degree. IPSTPs are needed between different sections to simplify the GT data and converge the SCTP association data. And it is recommended that M3UA should be used on the IPSTP-IPSEP interface, while M2PA may be used on the IPSTP- IPSTP interface. The architecture of IP based signalling network is as follows: +---------------+ +--------------+ | | | | +---IP---------+ IPSTP +--IP(M2PA)--+ IPSTP | | | | | | | +-------+-------+ +-------+------+ | Signalling transfer point Signalling transfer point | IP(M3UA) IP(M3UA) | +-------+-------+ +-------+-------+ (M3UA) | | | | | | IPSEP | | IPSEP | | | | | | | +---------------+ +---------------+ | Signalling end point Signalling end point | | +---------------+ | | | +------+ IPSEP | | | +---------------+ Signalling end point Figure 1: The architecture of IP based SS7 signalling network As same as the traditional TDM based SS7 signalling network, an IP based SS7 signalling network also provides signalling network management functions, such as signalling traffic management, signalling link management and signalling route management, to insure Chen, et al. Expires January 7, 2009 [Page 3] Internet-Draft extenting M3UA July 2008 the availability and traffic transport capacity of a signalling network in case of failures and congestion. Chen, et al. Expires January 7, 2009 [Page 4] Internet-Draft extenting M3UA July 2008 2. The Corresponding M3UA configuration in IP based signalling network There are 4 typical M3UA configurations in IP based signalling network. They are as follows: ******** IP ***************** IP ******** *IPSEP *---------* IPSTP *--------*IPSEP * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP | | SCCP | | SCCP | +------+ +---------------+ +------+ | M3UA | | M3UA | | M3UA | +------| +---------------+ +------+ | SCTP | | SCTP | | SCTP | +------+ +---------------+ +------+ | IP | | IP | | IP | +------+ +---------------+ +------+ |_______________| |______________| Figure 2: M3UA configuration for IPSEP-IPSTP-IPSEP application In this configuration, IPSTP provides MTP user signaling messages' transfer, M3UA management messages' transfer and SCCP signaling through IPSTP M3UA IPSP. ******** IP ***************** IP ******** *IPSEP *---------* IPSTP *--------*IPSTP * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP | | SCCP | | SCCP | | SCCP | +------+ +------+ +------+ +------+ | | | | | MTP3 | | MTP3 | | M3UA | | M3UA | +------+ +------+ | | | | | M2PA | | M2PA | +------| +------+-+------+ +------+ | SCTP | | SCTP | | SCTP | | SCTP | +------+ +------+ +------+ +------+ | IP | | IP | | IP | | IP | +------+ +------+ +------+ +------+ |_______________| |______________| Figure 3: M3UA configuration for IPSEP-IPSTP-IPSTP application In this configuration, IPSEP communicates with IPSTP through IPSTP. Chen, et al. Expires January 7, 2009 [Page 5] Internet-Draft extenting M3UA July 2008 ******** IP ***************** SS7 ******** *IPSEP *---------* IPSTP *--------* SEP * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP | | (NIF) | | SCCP | +------+ +------+ +------+ +------+ | M3UA | | M3UA | | MTP3 | | MTP3 | +------| +------+-+------+ +------+ | SCTP | | SCTP | | MTP2 | | MTP2 | +------+ +------+ +------+ +------+ | IP | | IP | | L1 | | L1 | +------+ +------+ +------+ +------+ |_______________| |______________| Figure 4: M3UA configuration for IPSEP-IPSTP-SEP In this configuration, IPSEP communicates with SEP through IPSTP. ******** IP ***************** SS7 ******** *IPSEP *---------* IPSTP *--------* STP * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP | | (NIF) | | SCCP | +------+ +------+ +------+ +------+ | M3UA | | M3UA | | MTP3 | | MTP3 | +------| +------+-+------+ +------+ | SCTP | | SCTP | | MTP2 | | MTP2 | +------+ +------+ +------+ +------+ | IP | | IP | | L1 | | L1 | +------+ +------+ +------+ +------+ |_______________| |______________| Figure 5: M3UA configuration for IPSEP-IPSTP-STP In this configuration, IPSEP communicates with STP through IPSTP. The correlated SCTP Client/Server Model for IPSTP-IPSEP interface is as follows: In the case of IPSTP to IPSEP communication, the default configuration would be--the IPSTP takes on the role of server while the IPSEP is the client. In this case, IPSEP SHOULD initiate the SCTP association to the IPSTP. Chen, et al. Expires January 7, 2009 [Page 6] Internet-Draft extenting M3UA July 2008 3. The requirement of extending M3UA signalling network route management For a large scale signalling network based on IP with IPSTPs, the usage of M2PA on IPSTP-IPSTP interface can help to realize the signalling network management between different sections of the signalling network. But M3UA can not fulfil the signalling network management within a section completely at present, the extension of it for this application is needed. The reason for the extension will be discussed in this section. Within a section of a large scale signalling network based on IP with IPSTPs, the normal signalling transport route between two IPSEPs will transit an IPSTP. When the destination IPSEP is not available(Scenario 1) , the IPSTP must notify the source IPSEP to choose another route. And when the user part of the destination IPSEP is not available (Scenario 2), the IPSTP must also notify the source IPSEP to stop the signalling traffic. Scenario 1: the destination SP is not available In Scenario 1, when IPSTP1 finds the destination IPSEP (AS,IPSEP2) in IP domain is not available,and there is no connection between IPSTP1 and IPSTP2,or the connection between IPSTP1 and IPSTP2 is not available. It is a matter of RFC4666 interpretation whether IPSTP1 sends a DUNA message or not to IPSEP1 upon failure of signaling connection towards IPSEP2.RFC4666 does not prohibit this, but it seems there is a bit of unclarity on whether SSNM Message can be sent by the IPSTP in the context of a AS->SG->AS interworking, while it is very clear that IPSTP can send such message in the context of SEP -> SG -> AS. In result, the source IPSEP (AS,IPSEP1) doesn't know the route is unavailable and still sends traffic to IPSTP1, which makes the signalling transport failure. Chen, et al. Expires January 7, 2009 [Page 7] Internet-Draft extenting M3UA July 2008 +---------------+ +--------------+ | | \ / | | +-- --+ IPSTP1 +--IP(M2PA)-\--+ IPSTP2 +-----+ | | | / \ | | | | +-------+-------+ +-------+------+ | | Signalling transfer point Signalling transfer point | | \ / | | | +---- IP(M3UA)-----\------+ | | | / \ | | | IP(M3UA) | | IP(M3UA) | | | | | | | | | | | |1 | | 3 | | | |DUNA | | DATA | | | | 2 DATA | | | | | | ---------------> | | | | |\|/ +-- IP(M3UA)--------------|----+ \|/ | | | | | | +-------+-------+ +----+----------+ | | | | | | | +-----+ IPSEP1 | | IPSEP2 +------+ | | | | +---------------+ +---------------+ Signalling end point Signalling end point Figure 6: Scenario 1 - the destination IPSEP is not available Scenario 2: the user part of the destination SP is not available In Scenario 2, when the user part of the destination IPSEP(AS,IPEP2 ) is not available, M3UA doesn't define the destination SP(AS,IPSEP2)'s M3UA layer can send proper SSNM message (DUPU) to notify the source IPSEP (AS, IPSEP1),and doesn't define IPSTP's M3UA layer can transfer the DUPU to the proper IPSEP(AS,IPSEP1) either. In addition ,DUPU contains no DPC field to indicate the address of the source IPSEP(AS,IPSEP1) which is the originator of the message( DATA) that triggered the DUPU. In result, the source IPSEP (AS,IPSEP1) doesn't know the user part of IPSEP2 is unavailable and still sends traffic to IPSEP2 , which makes the signalling transport failure. Chen, et al. Expires January 7, 2009 [Page 8] Internet-Draft extenting M3UA July 2008 +---------------+ | | +-- --+ IPSTP1 +----------------------+ | | | | | +---------------+ | | Signalling transfer point | | | | | | | IP(M3UA) IP(M3UA) | | |/|\ | /|\ | | | |1 |4 3 | 2 | | | |DATA |DUPU DUPU| DATA | | | | | | | | | | | | | | | | \|/ | \|/| | | | +---------------+ +------+---------+ | | | | \ / | +-----+ IPSEP1 | | \ IPSEP2 | | | | / \User Part| +---------------+ +----------------+ Signalling end point Signalling end point Figure 7: Scenario 2 -the user part of the destination SP is not available Base on the Scenarios discussed in this chapter, it is necessary to extend the signalling network route management function in M3UA. The following chapter provide the extention of signalling network route management in M3UA. Chen, et al. Expires January 7, 2009 [Page 9] Internet-Draft extenting M3UA July 2008 4. The proposal of extending M3UA signalling network route management In IP based SS7 signalling network, referring to the availability, a signalling route can be in five states for signalling traffic having the concerned destination; these are Destination uavailable, Destination available , Destination congested, Destination user part unavailable , Destination user part available. M3UA shall realize signalling network route management via the IPSTPs and IPSEPs sending the concerned messages. This document focuses on the route management about Destination uavailable/available and Destination user part unavailable/available. 4.1. The route management about Destination uavailable/available Because of the unavailability of the signalling route to an adjacent destination IPSEP, IPSTP shall report it to other adjacent IPSEPs by sending M3UA DUNA message, to other adjacent IPSTP/SEP/STPs through MTP3 TFP message. For IPSEP, when receiving a DUNA message, M3UA layer shall report to its user part the unavailability of the signaling route to the concerned destination IPSEP. For IPSTP/STP/ SEP, when receiving a TFP message, it shall handling the message according to Q.704. Because of the restored availability of the signalling route to an adjacent destination IPSEP, IPSTP shall report it to other adjacent IPSEPs by sending M3UA DAVA message, to other adjacent IPSTP/SEP/STPs through MTP3 TFA message. For IPSEP, when receiving a DAVA message, M3UA layer shall report to its user part the availability of the signaling route to the concerned destination IPSEP. For IPSTP/STP/ SEP, when receiving a TFA message, it shall handling the message according to Q.704. 4.2. The route management about Destination user part unavailable/ available 4.2.1. The route management description When IPSEP receives a M3UA layer DATA message, and finds that it could not be sent to appointed upper layer user, IPSEP shall send DUPU to the source point to indicate the reason: Unknown, Unequipped Remote User or Inaccessible Remote user. When IPSTP receives a M3UA DUPU message which contains: 1) The destination set to IPSTP itself. 2) The user part set to SCCP. M3UA layer shall report to its user part SCCP the unavailability of the concerned IPSEP's user part. Chen, et al. Expires January 7, 2009 [Page 10] Internet-Draft extenting M3UA July 2008 When IPSTP receives a M3UA DUPU message which contains: 1) The destination set to another PC . IPSTP may deliver it to the destination IPSEP directly, change the DUPU into a proper MTP3 UPU message and transfer it to the next signaling point(an IPSTP/STP),or change the DUPU into a proper MTP3 UPU message and transfer it to the destination SEP directly ,according to the route to the destination IPSEP/SEP. When IPSEP receives a M3UA DUPU message, M3UA layer shall report to its user part the unavailability of the concerned IPSEP's user part. For IPSTP/STP/SEP, when receiving a UPU message, it shall handling the message according to Q.704. Because of the restoration of Destination User Part, the concerned destination IPSEP will send M3UA DATA messages, which can indicate its user part restoration to the related IPSEPs/IPSTPs/STPs/SEPs. 4.2.2. The extension for DUPU massage The Destination User Part Unavailable (DUPU) message is extended as follows: A DUPU message is used by an SGP to inform concerned ASPs that a remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. This message is also used by IPSEP to inform IPSEP/SEP/IPSTP that its corresponding user layer is unavailable. A new field 'Concerned Destination' is introduced to DUPU message,which indicates Destination PC of the DUPU. The field 'Concerned Destination' has been defined in RFC4666 for SCON message, tag is 0x0206. The DUPU message contains the following parameters: Network Appearance Optional Routing Context Conditional Affected Point Code Mandatory Concerned Destination Mandatory User/Cause Mandatory INFO String Optional The format for DUPU message parameters is as follows: Chen, et al. Expires January 7, 2009 [Page 11] Internet-Draft extenting M3UA July 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0200 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Routing Context / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask = 0 | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Concerned Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0204 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause | User | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: DUPU message format Concerned Destination: 32 bits The Concerned Destination parameter contains one Concerned Destination Point Code field, a three-octet parameter to allow for 14-, 16-, and 24-bit binary formatted SS7 Point Codes. A Concerned Point Code that is less than 24 bits is padded on the left to the 24- bit boundary. When IPSEP receives a M3UA layer DATA message, and finds that it could not be sent to appointed upper layer user, IPSEP will feedback DUPU to the source point with the reason: Unknown, Unequipped Remote User or Inaccessible Remote user. In DUPU message, the Affected PC field contains the PC of the IPSEP Chen, et al. Expires January 7, 2009 [Page 12] Internet-Draft extenting M3UA July 2008 which sends this DUPU; the Concerned Destination field contains the source PC of the DATA message which triggers this DUPU. Concerned Destination field likes DPC field in MTP3 UPU message. Because DUPU is a M3UA SSNM message, which has no DPC field, IPSTP doesn't know the destination of this DUPU. By extending DUPU, IPSTP can know the destination of this DUPU from Concerned Destination field. 4.3. The Corresponding signalling node operation For IPSEP, - When receiving a M3UA layer DATA message, and M3UA laye finds that it could not be sent to appointed upper layer user, IPSEP shall send DUPU to the source point to indicate the reason: Unknown, Unequipped Remote User or Inaccessible Remote user. In DUPU message, the Affected PC field contains the PC of the IPSEP which sends this DUPU; the Concerned Destination field contains the source PC of the DATA message which triggers this DUPU. - When receiving a M3UA DUPU message, M3UA layer shall report to its related user part the unavailability of the Affected PC's user part.M3UA related User layer will not send DATA messages to the Affected PC'S corresponding user layer again. When receiving a M3UA DUNA message, M3UA layer shall report to its user part the unavailability of the signaling route to the concerned destination IPSEP. When receiving a M3UA DAVA message, M3UA layer shall report to its user part the availability of the signaling route to the concerned destination IPSEP. For IPSTP, -When receiving a DUPU message,its M3UA layer analyzes Concerned Destination field, if it's own PC and user is SCCP, reports to SCCP layer that Affected PC's SCCP is unavailable. So its SCCP will not send SCCP message to this Affected PC any more. If it is not its own PC, the IPSTP transmits this DUPU to corresponding signaling point(i.e. IPSEP or next jump IPSTP) according to the Concerned Destination in this DUPU and its routing table. -When receiving a M3UA layer DATA message, and M3UA laye finds that it could not be sent to SCCP layer, IPSTP shall send DUPU to the source point to indicate the reason: Unknown, Unequipped Remote User or Inaccessible Remote user. In DUPU message, the Affected PC field Chen, et al. Expires January 7, 2009 [Page 13] Internet-Draft extenting M3UA July 2008 contains the PC of itself; the Concerned Destination field contains the source PC of the DATA message which triggers this DUPU. -When adjacent IPSEP/SEP/STP/IPSTP availability status change, shall report it to IPSEP through DUNA/DAVA, to IPSTP/SEP/STP through TFP/ TFA. -When receiving DUNA/DAVA/TFP/TFA, shall report it to IPSEP through DUNA/DAVA, to IPSTP/SEP/STP through TFP/TFA. Chen, et al. Expires January 7, 2009 [Page 14] Internet-Draft extenting M3UA July 2008 5. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [2]. Chen, et al. Expires January 7, 2009 [Page 15] Internet-Draft extenting M3UA July 2008 6. IANA Considerations This document contains no new actions for IANA. Chen, et al. Expires January 7, 2009 [Page 16] Internet-Draft extenting M3UA July 2008 7. Security Considerations Implementations MUST follow the normative guidance of RFC3788 on the integration and usage of security mechanisms in SIGTRAN protocol. Chen, et al. Expires January 7, 2009 [Page 17] Internet-Draft extenting M3UA July 2008 8. Acknowledgments The authors wish to thank Peng Jin, Deng Hui, Zhang Juan and many others for their invaluable comments. Chen, et al. Expires January 7, 2009 [Page 18] Internet-Draft extenting M3UA July 2008 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC4666] Morneault, K. and J. Pastor-Balbas, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 4666, September 2006. Chen, et al. Expires January 7, 2009 [Page 19] Internet-Draft extenting M3UA July 2008 Authors' Addresses Xu Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: chenxu@chinamobile.com Hao Zhang China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: zhanghao@chinamobile.com Duan Xiaodong China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: duanxiaodong@chinamobile.com Zhao Yuyi China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: zhaoyuyi@chinamobile.com Chen, et al. Expires January 7, 2009 [Page 20] Internet-Draft extenting M3UA July 2008 Li Xinyan Alcatel Shanghai Bell Box 525 North XiZang Road, Shanghai China Email: xinyan.li@alcatel-sbell.com.cn Chen, et al. Expires January 7, 2009 [Page 21] Internet-Draft extenting M3UA July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. Chen, et al. Expires January 7, 2009 [Page 22]