draft-ietf-sigtran-rfc3332bis-05.txt   draft-ietf-sigtran-rfc3332bis-06.txt 
Network Working Group K. Morneault Network Working Group K. Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Expires: March 2006 Obsoletes: 3332 J. Pastor-Balbas
J. Pastor-Balbas
Ericsson Ericsson
Oct 2005 Feb 2006
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-05.txt> <draft-ietf-sigtran-rfc3332bis-06.txt>
STATUS OF THIS MEMO STATUS OF THIS MEMO
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 37
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. http://www.ietf.org/shadow.html.
This Internet-Draft will expire March 2006. This Internet-Draft will expire August 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006). 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
IP-based applications. It is assumed that the SG receives SS7 IP-based applications. It is assumed that the SG receives SS7
signalling over a standard SS7 interface using the SS7 Message signalling over a standard SS7 interface using the SS7 Message
Transfer Part (MTP) to provide transport. Transfer Part (MTP) to provide transport. This document obsoletes
RFC 3332.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.....................................................5 1. Introduction.....................................................5
1.1 Scope............................................................5 1.1 Scope............................................................5
1.2 Terminology......................................................5 1.2 Terminology......................................................5
1.3 M3UA Overview....................................................7 1.3 M3UA Overview....................................................7
1.4 Functional Areas................................................11 1.4 Functional Areas................................................11
1.5 Sample Configuration............................................18 1.5 Sample Configuration............................................18
1.6 Definition of M3UA Boundaries...................................20 1.6 Definition of M3UA Boundaries...................................20
skipping to change at page 12, line 48 skipping to change at page 12, line 48
Figure 2 Example with multiple Network Figure 2 Example with multiple Network
1.4.2 Routing Contexts and Routing Keys 1.4.2 Routing Contexts and Routing Keys
1.4.2.1 Overview 1.4.2.1 Overview
The distribution of SS7 messages between the SGP and the Application The distribution of SS7 messages between the SGP and the Application
Servers is determined by the Routing Keys and their associated Servers is determined by the Routing Keys and their associated
Routing Contexts. A Routing Key is essentially a set of SS7 Routing Contexts. A Routing Key is essentially a set of SS7
parameters used to filter SS7 messages, whereas the Routing Context parameters used to filter SS7 messages, whereas the Routing Context
parameter is a 4-byte value (integer) that is associated to that parameter is a 4-octet value (integer) that is associated to that
Routing Key in a 1:1 relationship. The Routing Context therefore can Routing Key in a 1:1 relationship. The Routing Context therefore can
be viewed as an index into a sending node's Message Distribution be viewed as an index into a sending node's Message Distribution
Table containing the Routing Key entries. Table containing the Routing Key entries.
Possible SS7 address/routing information that comprise a Routing Key Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example, the OPC, DPC, SIO found in the MTP3 entry includes, for example, the OPC, DPC, SIO found in the MTP3
routing label. Some example Routing Keys are: the DPC alone, the routing label. Some example Routing Keys are: the DPC alone, the
DPC/OPC combination, or the DPC/OPC/SI combination. The particular DPC/OPC combination, or the DPC/OPC/SI combination. The particular
information used to define an M3UA Routing Key is application and information used to define an M3UA Routing Key is application and
network dependent, and none of the above examples are mandated. network dependent, and none of the above examples are mandated.
skipping to change at page 27, line 26 skipping to change at page 27, line 26
3.1.3 Reserved: 8 bits 3.1.3 Reserved: 8 bits
The Reserved field SHOULD be set to all '0's and ignored by the The Reserved field SHOULD be set to all '0's and ignored by the
receiver. receiver.
3.1.4 Message Length: 32-bits (unsigned integer) 3.1.4 Message Length: 32-bits (unsigned integer)
The Message Length defines the length of the message in octets, The Message Length defines the length of the message in octets,
including the Common Header. The Message Length MUST include including the Common Header. The Message Length MUST include
parameter padding bytes, if any. parameter padding octets, if any.
Note: A receiver SHOULD accept the message whether or not the final Note: A receiver SHOULD accept the message whether or not the final
parameter padding is included in the message length. parameter padding is included in the message length.
3.2 Variable Length Parameter Format 3.2 Variable Length Parameter Format
M3UA messages consist of a Common Header followed by zero or more M3UA messages consist of a Common Header followed by zero or more
variable length parameters, as defined by the message type. All the variable length parameters, as defined by the message type. All the
parameters contained in a message are defined in a Tag Length-Value parameters contained in a message are defined in a Tag Length-Value
format as shown below. format as shown below.
skipping to change at page 29, line 21 skipping to change at page 29, line 21
Reserved by the IETF 0x0214 to 0xffff Reserved by the IETF 0x0214 to 0xffff
The value of 65535 is reserved for IETF-defined extensions. The value of 65535 is reserved for IETF-defined extensions.
Values other than those defined in specific parameter description Values other than those defined in specific parameter description
are reserved for use by the IETF. A RFC is required to make use are reserved for use by the IETF. A RFC is required to make use
of parameter values "Reserved by the IETF". of parameter values "Reserved by the IETF".
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter The Parameter Length field contains the size of the parameter
in bytes, including the Parameter Tag, Parameter Length, and in octets, including the Parameter Tag, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes. If the Parameter Length does not include any padding octets. If the
parameter contains subparameters, the Parameter Length field parameter contains subparameters, the Parameter Length field
will include all the bytes of each subparameter including will include all the octets of each subparameter including
subparameter padding bytes (if any). subparameter padding octets (if any).
Parameter Value: variable length. Parameter Value: variable length.
The Parameter Value field contains the actual information to be The Parameter Value field contains the actual information to be
transferred in the parameter. transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length The total length of a parameter (including Tag, Parameter Length
and Value fields) MUST be a multiple of 4 bytes. If the length of and Value fields) MUST be a multiple of 4 octets. If the length of
the parameter is not a multiple of 4 bytes, the sender pads the the parameter is not a multiple of 4 octets, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with Parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is NOT included in the all zero octets. The length of the padding is NOT included in the
parameter length field. A sender MUST NOT pad with more than 3 parameter length field. A sender MUST NOT pad with more than 3
bytes. The receiver MUST ignore the padding bytes. octets. The receiver MUST ignore the padding octets.
3.3 Transfer Messages 3.3 Transfer Messages
The following section describes the Transfer messages and parameter The following section describes the Transfer messages and parameter
contents. contents.
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
skipping to change at page 32, line 37 skipping to change at page 32, line 37
priority bits. The MP bits are aligned to the least significant bit. priority bits. The MP bits are aligned to the least significant bit.
Unused bits are coded `0'. Unused bits are coded `0'.
Signalling Link Selection: 8 bits (unsigned integer) Signalling Link Selection: 8 bits (unsigned integer)
The Signalling Link Selection field contains the SLS bits from the The Signalling Link Selection field contains the SLS bits from the
routing label of the original SS7 message justified to the least routing label of the original SS7 message justified to the least
significant bit and in Network Byte Order. Unused bits are coded significant bit and in Network Byte Order. Unused bits are coded
`0'. `0'.
User Protocol Data: (variable length byte string) User Protocol Data: (variable length octet string)
The User Protocol Data field contains a byte string of MTP-User The User Protocol Data field contains a octet string of MTP-User
information from the original SS7 message starting with the information from the original SS7 message starting with the
first byte of the original SS7 message following the Routing first octet of the original SS7 message following the Routing
Label [7][8][29]. Label [7][8][29].
Correlation Id: 32-bits (unsigned integer) Correlation Id: 32-bits (unsigned integer)
The Correlation Id parameter uniquely identifies the MSU carried in The Correlation Id parameter uniquely identifies the MSU carried in
the Protocol Data within an AS. This Correlation Id parameter is the Protocol Data within an AS. This Correlation Id parameter is
assigned by the sending M3UA. assigned by the sending M3UA.
3.4 SS7 Signalling Network Management (SSNM) Messages 3.4 SS7 Signalling Network Management (SSNM) Messages
skipping to change at page 58, line 54 skipping to change at page 58, line 54
0x1a No Configured AS for ASP 0x1a No Configured AS for ASP
The "Invalid Version" error is sent if a message with an unsupported The "Invalid Version" error is sent if a message with an unsupported
version is received, the receiving end responds with an Error message, version is received, the receiving end responds with an Error message,
indicating the version the receiving node supports and notifies layer indicating the version the receiving node supports and notifies layer
management. management.
The "Unsupported Message Class" error is sent if a message with an The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. For this error, unexpected or unsupported Message Class is received. For this error,
the Diagnostic Information parameter MUST be included with the first the Diagnostic Information parameter MUST be included with the first
40 bytes of the offending message. 40 octets of the offending message.
The "Unsupported Message Type" error is sent if a message with an The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. For this error, unexpected or unsupported Message Type is received. For this error,
the Diagnostic Information parameter MUST be included with the first the Diagnostic Information parameter MUST be included with the first
40 bytes of the offending message. 40 octets of the offending message.
The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP
sends an ASP Active message with an unsupported Traffic Mode Type or sends an ASP Active message with an unsupported Traffic Mode Type or
a Traffic Mode Type that is inconsistent with the presently a Traffic Mode Type that is inconsistent with the presently
configured mode for the Application Server. An example would be a configured mode for the Application Server. An example would be a
case in which the SGP did not support loadsharing. case in which the SGP did not support loadsharing.
The "Unexpected Message" error MAY be sent if a defined and The "Unexpected Message" error MAY be sent if a defined and
recognized message is received that is not expected in the current recognized message is received that is not expected in the current
state (in some cases the ASP may optionally silently discard the state (in some cases the ASP may optionally silently discard the
skipping to change at page 75, line 7 skipping to change at page 75, line 7
different (sets of) Routing Contexts. different (sets of) Routing Contexts.
The ASP Active message will be responded in the following way as a The ASP Active message will be responded in the following way as a
function of the presence/need of the RC parameter: function of the presence/need of the RC parameter:
- If the RC parameter is included in the ASP Active message and the - If the RC parameter is included in the ASP Active message and the
corresponding RK has been previously defined (by either static corresponding RK has been previously defined (by either static
configuration or dynamic registration), the peer node MUST respond configuration or dynamic registration), the peer node MUST respond
with an ASP Active Ack message. If for any local reason (e.g. with an ASP Active Ack message. If for any local reason (e.g.
management lockout) the SGP responds t an ASP Active message with an management lockout) the SGP responds t an ASP Active message with an
Error message with reason "Refused Management Blocking". Error message with reason "Refused Management Blocking".
- If the RC parameter is included in the ASP Active message and a - If the RC parameter is included in the ASP Active message and a
corresponding RK has not been previously defined (by either static corresponding RK has not been previously defined (by either static
configuration or dynamic registration), the peer MUST respond with configuration or dynamic registration), the peer MUST respond with
an ERROR message with Error Code = "No configured AS for ASP". an ERROR message with Error Code = "No configured AS for ASP".
- If the RC parameter is not included in the ASP Active message, there - If the RC parameter is not included in the ASP Active message, there
are RKs defined (by either static configuration or dynamic are RKs defined (by either static configuration or dynamic
registration) and RC is not mandatory, the peer node SHOULD respond registration) and RC is not mandatory, the peer node SHOULD respond
with an ASP Active Ack message and activate all the RKs it has with an ASP Active Ack message and activate all the RKs it has
skipping to change at page 82, line 39 skipping to change at page 82, line 39
code, the RC field in the Registration Response message MUST be code, the RC field in the Registration Response message MUST be
populated with the actual value of RC in SGP corresponding to the populated with the actual value of RC in SGP corresponding to the
specified RK in the Registration Request message. specified RK in the Registration Request message.
An ASP MAY request modification of an existing Routing Key by An ASP MAY request modification of an existing Routing Key by
including a Routing Context parameter in a Registration Request including a Routing Context parameter in a Registration Request
message. Upon receipt of a Registration Request message containing a message. Upon receipt of a Registration Request message containing a
Routing Context, if the SGP determines that the Routing Context Routing Context, if the SGP determines that the Routing Context
applies to an existing Routing Key, the SGP MAY adjust the existing applies to an existing Routing Key, the SGP MAY adjust the existing
Routing Key to match the new information provided in the Routing Key Routing Key to match the new information provided in the Routing Key
parameter. A Registration Response "ERR Routing Key Change Refused" parameter. A Registration Response "ERR Routing Key Change Refused"
is returned if the SGP does not support this re-registration procedure is returned if the SGP does not support this re-registration procedure
or RC does not exist. Otherwise, a Registration Response "Successfully or RC does not exist. Otherwise, a Registration Response "Successfully
Registered" is returned. Registered" is returned.
If the SGP does not authorize an otherwise valid registration request, If the SGP does not authorize an otherwise valid registration request,
the SGP returns a REG RSP message to the ASP containing the the SGP returns a REG RSP message to the ASP containing the
Registration Result "Error - Permission Denied". Registration Result "Error - Permission Denied".
If an SGP determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SGP does not support dynamic configuration, the SGP exist and the SGP does not support dynamic configuration, the SGP
skipping to change at page 104, line 17 skipping to change at page 104, line 17
[7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7 [7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)" (SS7) - Message Transfer Part (MTP)"
[8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part" [8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
[9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); [9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Message Transfer Part (MTP) to support Signalling System No.7; Message Transfer Part (MTP) to support
international interconnection; Part 1: Protocol specification" international interconnection; Part 1: Protocol specification"
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 3629, November 2003.
[11] Loughney, J., Tuexen, M., Pastor-Balbas, J., "Security
Considerations for Signaling Transport (SIGTRAN) Protocols",
RFC 3788, June 2004.
8.2 Informative References 8.2 Informative References
[11] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H., [12] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H.,
Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for
Signaling Transport", RFC 2719, October 1999. Signaling Transport", RFC 2719, October 1999.
[12] ITU-T Recommendation Q.720, "Telephone User Part" [13] ITU-T Recommendation Q.720, "Telephone User Part"
[13] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 [14] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7
(SS7) - Transaction Capabilities (TCAP)" (SS7) - Transaction Capabilities (TCAP)"
[14] ANSI T1.114 "Signaling System Number 7 - Transaction [15] ANSI T1.114 "Signaling System Number 7 - Transaction
Capabilities Application Part" Capabilities Application Part"
[15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); [16] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2; Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification" Part 1: Protocol specification"
[16] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd [17] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
Generation partnership Project; Technical Specification Group Generation partnership Project; Technical Specification Group
Radio Access Network; UTRAN Iu Interface: General Aspects and Radio Access Network; UTRAN Iu Interface: General Aspects and
Principles" Principles"
[17] Stewart, R., Xie, Q., Morneault, K., Sharp, H., Taylor, T., [18] Stewart, R., Xie, Q., Morneault, K., Sharp, H., Taylor, T.,
Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control
Transport Protocol", RFC 2960, October 2000. Transport Protocol", RFC 2960, October 2000.
[18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - [19] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer -
Service Specific Coordination Function for signalling at the Service Specific Coordination Function for signalling at the
Network Node Interface (SSCF at NNI)" Network Node Interface (SSCF at NNI)"
[19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - [20] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer -
Service Specific Connection Oriented Protocol (SSCOP)" Service Specific Connection Oriented Protocol (SSCOP)"
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[21] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 [22] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3
functions and messages using the services of ITU Recommendation functions and messages using the services of ITU Recommendation
Q.2140" Q.2140"
[22] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September [23] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September
1997. 1997.
[23] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture [24] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture
for the Internet Protocol", RFC 3168, November 1998. for the Internet Protocol", RFC 3168, November 1998.
[24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [25] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[25] Maughan, D., Schertler, M., Schneider, M. and J. Turner, [26] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management Protocol", RFC "Internet Security Association and Key Management Protocol", RFC
2408, November 1998. 2408, November 1998.
[26] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA [27] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[27] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. [28] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J.
Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
- User Adaptation Layer", RFC 3331, August 2002. - User Adaptation Layer", RFC 3331, August 2002.
[28] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation [29] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation
Layer", Work in Progress. Layer", Work in Progress.
[29] Telecommunication Technology Committee (TTC) Standard JT-Q704, [30] Telecommunication Technology Committee (TTC) Standard JT-Q704,
"Message Transfer Part Signaling Network Functions", April 28, "Message Transfer Part Signaling Network Functions", April 28,
1992. 1992.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Antonio Roque Alvarez, Joyce The authors would like to thank Antonio Roque Alvarez, Joyce
Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes,
Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite, Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite,
Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois
Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal
skipping to change at page 106, line 26 skipping to change at page 106, line 26
2. removed support for CIC and SSN as parameters for Routing Keys 2. removed support for CIC and SSN as parameters for Routing Keys
3. fixed grammar and spelling errors 3. fixed grammar and spelling errors
4. updated language on "n+k" redundancy 4. updated language on "n+k" redundancy
5. added language to address forward compatibility with future 5. added language to address forward compatibility with future
versions of the protocol versions of the protocol
6. fixed language regarding pad bytes 6. fixed language regarding pad octets
7. added additional error return values for Routing Key 7. added additional error return values for Routing Key
Registration Registration
8. clarified text regarding ASP states and state changes 8. clarified text regarding ASP states and state changes
9. clarified text regarding IPSP SE and DE models, updated state 9. clarified text regarding IPSP SE and DE models, updated state
diagrams to include IPSP information diagrams to include IPSP information
10. fixed a few errors in message flow examples 10. fixed a few errors in message flow examples
skipping to change at page 113, line 41 skipping to change at page 113, line 41
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 Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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. 43 change blocks. 
46 lines changed or deleted 50 lines changed or added

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