draft-ietf-sigtran-rfc3332bis-02.txt   draft-ietf-sigtran-rfc3332bis-03.txt 
Network Working Group K. Morneault Network Working Group K. Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Expires: April 11, 2004 Expires: November 2005
J. Pastor-Balbas J. Pastor-Balbas
Ericsson Ericsson
October 12, 2004 May 2005
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
User Adaptation Layer (M3UA) User Adaptation Layer (M3UA)
<draft-ietf-sigtran-rfc3332bis-02.txt> <draft-ietf-sigtran-rfc3332bis-03.txt>
STATUS OF THIS MEMO STATUS OF THIS MEMO
By submitting this Internet-Draft, each author certifies that any This document is an Internet-Draft and is subject to all provisions
applicable patent or other IPR claims of which they are aware have of Section 3 of RFC 3667. By submitting this Internet-Draft, each
been disclosed, and any of which they become aware will be disclosed, author represents that any applicable patent or other IPR claims of
in accordance with RFC 3668. 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 Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.This document is an Internet-Draft and http://www.ietf.org/shadow.html.
is in full conformance with all provisions of Section 10 of RFC2026.
This Internet-Draft will expire November 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This memo defines a protocol for supporting the transport of any SS7 This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol. Also, services of the Stream Control Transmission Protocol. Also,
provision is made for protocol elements that enable a seamless provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database, or between two Gateway Controller (MGC) or IP-resident Database, or between two
skipping to change at page 3, line 43 skipping to change at page 3, line 43
4.8 M3UA Version Control............................................88 4.8 M3UA Version Control............................................88
4.9 M3UA Termination................................................88 4.9 M3UA Termination................................................88
5. Examples of M3UA Procedures......................................88 5. Examples of M3UA Procedures......................................88
5.1 Establishment of Association and Traffic between SGPs and ASPs..88 5.1 Establishment of Association and Traffic between SGPs and ASPs..88
5.2 ASP Traffic Failover Examples...................................94 5.2 ASP Traffic Failover Examples...................................94
5.3 Normal Withdrawal of an ASP from an Application Server..........95 5.3 Normal Withdrawal of an ASP from an Application Server..........95
5.4 Auditing examples...............................................96 5.4 Auditing examples...............................................96
5.5 M3UA/MTP3-User Boundary Examples................................96 5.5 M3UA/MTP3-User Boundary Examples................................96
5.6 Examples for IPSP communication................................100 5.6 Examples for IPSP communication................................100
6. Security Considerations.........................................101 6. Security Considerations.........................................101
6.1 Introduction...................................................101 7. IANA Considerations.............................................101
6.2 Threats........................................................102
6.3 Protecting Confidentiality.....................................102
7. IANA Considerations.............................................102
7.1 SCTP Payload Protocol Identifier...............................102 7.1 SCTP Payload Protocol Identifier...............................102
7.2 M3UA Port Number...............................................103 7.2 M3UA Port Number...............................................102
7.3 M3UA Protocol Extensions.......................................103 7.3 M3UA Protocol Extensions.......................................103
8. References......................................................104 8. References......................................................103
8.1 Normative References...........................................104 8.1 Normative References...........................................103
8.2 Informative References.........................................105 8.2 Informative References.........................................104
9. Acknowledgements................................................106 9. Acknowledgements................................................105
10. Document Contributors..........................................106 10. Document Contributors..........................................106
Appendix A.........................................................108 11. Change Log.....................................................106
Appendix A.........................................................107
A.1 Signalling Network Architecture................................108 A.1 Signalling Network Architecture................................108
A.2 Redundancy Models..............................................110 A.2 Redundancy Models..............................................110
Editors' Addresses.................................................113 Editors' Addresses.................................................113
1. Introduction 1. Introduction
This memo defines a protocol for supporting the transport of any SS7 This memo defines a protocol for supporting the transport of any SS7
MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
services of the Stream Control Transmission Protocol [17]. Also, services of the Stream Control Transmission Protocol [17]. Also,
provision is made for protocol elements that enable a seamless provision is made for protocol elements that enable a seamless
skipping to change at page 28, line 17 skipping to change at page 28, line 17
The Tag field is a 16-bit identifier of the type of parameter. It The Tag field is a 16-bit identifier of the type of parameter. It
takes a value of 0 to 65534. Common parameters used by adaptation takes a value of 0 to 65534. Common parameters used by adaptation
layers are in the range of 0x00 to 0x3f. M3UA-specific layers are in the range of 0x00 to 0x3f. M3UA-specific
parameters have Tags in the range 0x0200 to 0x02ff. The parameter parameters have Tags in the range 0x0200 to 0x02ff. The parameter
Tags defined are as follows: Tags defined are as follows:
Common Parameters. These TLV parameters are common across the Common Parameters. These TLV parameters are common across the
different adaptation layers: different adaptation layers:
Parameter Name Parameter ID Parameter Name Parameter ID
============== ============ ============== =========== Reserved 0x0000
Reserved 0x0000
Not Used in M3UA 0x0001 Not Used in M3UA 0x0001
Not Used in M3UA 0x0002 Not Used in M3UA 0x0002
Not Used in M3UA 0x0003 Not Used in M3UA 0x0003
INFO String 0x0004 INFO String 0x0004
Not Used in M3UA 0x0005 Not Used in M3UA 0x0005
Routing Context 0x0006 Routing Context 0x0006
Diagnostic Information 0x0007 Diagnostic Information 0x0007
Not Used in M3UA 0x0008 Not Used in M3UA 0x0008
Heartbeat Data 0x0009 Heartbeat Data 0x0009
Not Used in M3UA 0x000a Not Used in M3UA 0x000a
skipping to change at page 95, line 17 skipping to change at page 95, line 17
|<----------------------------------------ASP Act (Ldshr)---| |<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->| |------------------------------------------ASP Act (Ack)--->|
| | | | | | | |
|-NTFY(AS-ACTIVE)-->| | | |-NTFY(AS-ACTIVE)-->| | |
|-------------------NOTIFY(AS-ACTIVE)-->| | |-------------------NOTIFY(AS-ACTIVE)-->| |
|---------------------------------------NOTIFY(AS-ACTIVE)-->| |---------------------------------------NOTIFY(AS-ACTIVE)-->|
| | | | | | | |
| | | | | | | |
For the Notify message to be sent, the SG maintains knowledge of the For the Notify message to be sent, the SG maintains knowledge of the
minimum ASP resources required (e.g., if the SG knows that "n+k" = minimum ASP resources required (e.g., if the SG knows that "n+k" "2+1" for a Loadshare AS and "n" currently equals "1").
"2+1" for a Loadshare AS and "n" currently equals "1").
Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA
heartbeat loss or detection of SCTP failure), the initial ASP heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., SGP-ASP1) would not occur. Inactive message exchange (i.e., SGP-ASP1) would not occur.
5.3 Normal Withdrawal of an ASP from an Application Server 5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association and Teardown of an Association
An ASP which is now confirmed in the state ASP-INACTIVE (i.e., the An ASP which is now confirmed in the state ASP-INACTIVE (i.e., the
ASP has received an ASP Inactive Ack message) may now proceed to the ASP has received an ASP Inactive Ack message) may now proceed to the
skipping to change at page 100, line 39 skipping to change at page 100, line 39
| | | |
5.6 Examples for IPSP communication. 5.6 Examples for IPSP communication.
These scenarios show a basic example for IPSP communication for the These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange, three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already disconnection). It is assumed that the SCTP association is already
set up. Both single exchange and double exchange behavior are set up. Both single exchange and double exchange behavior are
included for illustrative purposes. included for illustrative purposes.
5.6.1 Single exchange: 5.6.1 Single exchange
IPSP-A IPSP-B IPSP-A IPSP-B
| | | |
|-------------ASP Up------------>| |-------------ASP Up------------>|
|<----------ASP Up Ack-----------| |<----------ASP Up Ack-----------|
| | | |
|<------- ASP Active(RCb)--------| RC: Routing Context |<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional) |-----ASP Active Ack (RCb)------>| (optional)
| | | |
| | | |
skipping to change at page 101, line 11 skipping to change at page 101, line 11
|<-----ASP Inactive (RCb)--------| RC: Routing Context |<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional) |----ASP Inactive Ack (RCb)----->| (optional)
| | | |
|<-----------ASP Down------------| |<-----------ASP Down------------|
|---------ASP Down Ack---------->| |---------ASP Down Ack---------->|
| | | |
Routing Context are previously agreed to be the same in both Routing Context are previously agreed to be the same in both
directions. directions.
5.6.2 Double exchange: 5.6.2 Double exchange
IPSP-A IPSP-B IPSP-A IPSP-B
| | | |
|<-------------ASP Up------------| |<-------------ASP Up------------|
|-----------ASP Up Ack---------->| |-----------ASP Up Ack---------->|
| | | |
|-------------ASP Up------------>| (optional) |-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional) |<----------ASP Up Ack-----------| (optional)
| | | |
|<------- ASP Active(RCb)--------| RC: Routing Context |<------- ASP Active(RCb)--------| RC: Routing Context
skipping to change at page 101, line 54 skipping to change at page 101, line 54
considered as enough since the response by the other peer can be considered as enough since the response by the other peer can be
considered as a notice that it is in ASP_UP state. considered as a notice that it is in ASP_UP state.
For the same reason, only one ASP Down message is needed since once For the same reason, only one ASP Down message is needed since once
that an IPSP receives ASP_Down ack message it is itself considered as that an IPSP receives ASP_Down ack message it is itself considered as
being in the ASP_Down state and not allowed to receive ASPSM being in the ASP_Down state and not allowed to receive ASPSM
messages. messages.
6. Security Considerations 6. Security Considerations
6.1 Introduction The security considerations discussed for the 'Security
M3UA is designed to carry signalling messages for telephony services. Considerations for SIGTRAN Protocols' RFC 3788 [3] document apply
As such, M3UA must involve the security needs of several parties: the to this document.
end users of the services; the network providers and the applications
involved. Additional requirements may come from local regulation.
While having some overlapping security needs, any security solution
should fulfill all of the different parties' needs.
6.2 Threats
There is no quick fix, one-size-fits-all solution for security. As a
transport protocol, M3UA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
M3UA is recommended to be transported on SCTP. SCTP [17] provides
certain transport related security features, such as some protection
against:
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When M3UA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [22] should be consulted for guidance.
When the network in which M3UA runs in involves more than one party,
it may not be reasonable to expect that all parties have implemented
security in a sufficient manner. In such a case, it is recommended
that IPSEC is used to ensure confidentiality of user payload.
Consult [23] for more information on configuring IPSEC services.
6.3 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality
may include the masking of IP addresses and ports. In this case
application level encryption is not sufficient; IPSEC ESP [24] SHOULD
be used instead. Regardless of which level performs the encryption,
the IPSEC ISAKMP [25] service SHOULD be used for key management.
7. IANA Considerations 7. IANA Considerations
This document contains no actions for IANA. Instead, it is retained
for historical purposes.
7.1 SCTP Payload Protocol Identifier 7.1 SCTP Payload Protocol Identifier
IANA has assigned an M3UA value for the Payload Protocol Identifier IANA has assigned an M3UA value for the Payload Protocol Identifier
in the SCTP DATA chunk. The following SCTP Payload Protocol in the SCTP DATA chunk. The following SCTP Payload Protocol
Identifier is registered: Identifier has been registered:
M3UA "3" M3UA "3"
The SCTP Payload Protocol Identifier value "3" SHOULD be included in The SCTP Payload Protocol Identifier value "3" SHOULD be included in
each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA
protocol. The value "0" (unspecified) is also allowed but any other protocol. The value "0" (unspecified) is also allowed but any other
values MUST not be used. This Payload Protocol Identifier is not values MUST not be used. This Payload Protocol Identifier is not
directly used by SCTP but MAY be used by certain network entities to directly used by SCTP but MAY be used by certain network entities to
identify the type of information being carried in a DATA chunk. identify the type of information being carried in a DATA chunk.
skipping to change at page 103, line 38 skipping to change at page 102, line 48
This protocol may also be extended through IANA in three ways: This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes, -- through definition of additional message classes,
-- through definition of additional message types, and -- through definition of additional message types, and
-- through definition of additional message parameters -- through definition of additional message parameters
The definition and use of new message classes, types and parameters The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus these is an integral part of SIGTRAN adaptation layers. Thus these
extensions are assigned by IANA through an IETF Consensus action as extensions are assigned by IANA through an IETF Consensus action as
defined in Guidelines for Writing an IANA Considerations Section in defined in Guidelines for Writing an IANA Considerations Section in
RFCs (25] RFCs [25].
The proposed extension must in no way adversely affect the general The proposed extension must in no way adversely affect the general
working of the protocol. working of the protocol.
7.3.1 IETF Defined Message Classes 7.3.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following The documentation for a new message class MUST include the following
information: information:
(a) A long and short name for the new message class; (a) A long and short name for the new message class;
skipping to change at page 108, line 5 skipping to change at page 106, line 11
Lyndon Ong - Ciena Lyndon Ong - Ciena
Hanns Juergen Schwarzbauer - Siemens Hanns Juergen Schwarzbauer - Siemens
Klaus Gradischnig - Detecon Inc. Klaus Gradischnig - Detecon Inc.
Mallesh Kalla - Telcordia Mallesh Kalla - Telcordia
Normand Glaude - Performance Technologies Normand Glaude - Performance Technologies
Brian Bidulock - OpenSS7 Brian Bidulock - OpenSS7
John Loughney - Nokia John Loughney - Nokia
Greg Sidebottom - Signatus Technologies Greg Sidebottom - Signatus Technologies
11. Change Log (as compared to RFC3332)
Below is a summary of differences between this document and RFC3332.
1. updated security section
2. removed support for CIC and SSN as parameters for Routing Keys
3. fixed grammar and spelling errors
4. updated language on "n+k" redundancy
5. added language to address forward compatibility with future
versions of the protocol
6. fixed language regarding pad bytes
7. added additional error return values for Routing Key
Registration
8. clarified text regarding ASP states and state changes
9. clarified text regarding IPSP SE and DE models, updated state
diagrams to include IPSP information
10. fixed a few errors in message flow examples
Appendix A Appendix A
A.1 Signalling Network Architecture A.1 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction requirements for such transport by itself. However, the conjunction
of distributed architecture and redundant networks provides support of distributed architecture and redundant networks provides support
skipping to change at page 109, line 8 skipping to change at page 108, line 8
considered. As an example, for a particular Application Server, the considered. As an example, for a particular Application Server, the
related ASPs could be distributed over at least two Hosts. related ASPs could be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7 One example of a physical network architecture relevant to SS7
carrier grade operation in the IP network domain is shown in Figure A- carrier grade operation in the IP network domain is shown in Figure A-
1 below: 1 below:
SGs MGCs SGs MGCs
Host#1 ************** ************** Host#3 Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * = * ********__*__________________________*__******** * * *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** * * ******** * \ / * ******** *
* ********__*______\__/________________*__******** * * ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * * * *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** * * ******** * /\ | | * ******** *
* : * / \ | | * : * * : * / \ | | * : *
* ******** * / \ | | * ******** * * ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * * * * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** * * ******** * | | | | * ******** *
************** | | | | ************** ************** | | | | **************
| | \ / | | \ /
Host#2 ************** | | \ / ************** Host#4 Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * = * ********__*_____| |______\/_______*__******** * * *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** * * ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** * * ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * * * *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** * * ******** * * ******** *
* : * SCTP Associations * : * * : * SCTP Associations * : *
* ******** * * ******** * * ******** * * ******** *
* * SGPn * * * * ASPn * * * * SGPn * * * * ASPn * *
* ******** * * ******** * * ******** * * ******** *
************** ************** ************** **************
skipping to change at page 114, line 5 skipping to change at page 113, line 5
EMail: kmorneau@cisco.com EMail: kmorneau@cisco.com
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Espana S.A. Ericsson Espana S.A.
C/ Retama 1 C/ Retama 1
28045 Madrid - Spain 28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.com EMail: j.javier.pastor@ericsson.com
Intellectual Property Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology pertain to the implementation or use of the technology described in
described in this document or the extent to which any license this document or the extent to which any license under such rights
under such rights might or might not be available; nor does it might or might not be available; nor does it represent that it has
represent that it has made any independent effort to identify any made any independent effort to identify any such rights. Information
such rights. Information on the procedures with respect to on the procedures with respect to rights in RFC documents can be
rights in RFC documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. 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.
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject The IETF invites any interested party to bring to its attention any
to the rights, licenses and restrictions contained in BCP 78, and copyrights, patents or patent applications, or other proprietary
except as set forth therein, the authors retain all their rights. 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 Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/