draft-ietf-sigtran-m2ua-05.txt   draft-ietf-sigtran-m2ua-06.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Tom George Tom George
Alcatel Alcatel
Expires in six months Nov 2000 Expires in six months Nov 2000
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-05.txt> <draft-ietf-sigtran-m2ua-06.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups MAY also distribute and its working groups. Note that other groups MAY also distribute
working documents as Internet-Drafts. 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.1 Procedures to Support Service in Section 1.4.1........20 4.1 Procedures to Support Service in Section 1.4.1........20
4.2 Procedures to Support Service in Section 1.4.2........21 4.2 Procedures to Support Service in Section 1.4.2........21
4.3 Procedures to Support Service in Section 1.4.3........21 4.3 Procedures to Support Service in Section 1.4.3........21
5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26 5. Examples of MTP2 User Adaptation (M2UA) Procedures.......26
5.1 Establishment of associations between SG and MGC......26 5.1 Establishment of associations between SG and MGC......26
examples examples
5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28 5.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28
5.3 Layer Management Communication Examples...............29 5.3 Layer Management Communication Examples...............29
6. Security.................................................30 6. Security.................................................30
7. IANA Considerations......................................31 7. IANA Considerations......................................31
7.1 SCTP Payload Protocol Identifier.......................31
7.2 IUA Protocol Extensions................................31
8. Acknowledgements.........................................31 8. Acknowledgements.........................................31
9. References...............................................32 9. References...............................................32
10. Author's Addresses.......................................33 10. Author's Addresses.......................................33
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network SCN signaling protocol There is a need for Switched Circuit Network SCN signaling protocol
delivery from an Signaling Gateway (SG) to a Media Gateway delivery from an Signaling Gateway (SG) to a Media Gateway
skipping to change at page 5, line 99 skipping to change at page 5, line 99
to-end network architecture between an SS7 node and an IP ASP. to-end network architecture between an SS7 node and an IP ASP.
Depending of course on the reliability of the SG and ASP functional Depending of course on the reliability of the SG and ASP functional
elements, this can typically be met by the spreading links in a linkset elements, this can typically be met by the spreading links in a linkset
across SGs, the provision of redundant QOS-bounded IP network paths for across SGs, the provision of redundant QOS-bounded IP network paths for
SCTP Associations between SCTP End Points, and redundant Hosts. The SCTP Associations between SCTP End Points, and redundant Hosts. The
distribution of ASPs within the available Hosts is also important. For a distribution of ASPs within the available Hosts is also important. For a
particular Application Server, the related ASPs SHOULD be distributed over particular Application Server, the related ASPs SHOULD be distributed over
at least two Hosts. at least two Hosts.
An example physical network architecture relevant to carrier-grade An example logical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 2 below: operation in the IP network domain is shown in Figure 2 below:
******** ************** ******** **************
* *_________________________________________* ******** * Host1 * *_________________________________________* ******** * Host1
* * _________* * ASP1 * * * * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** * * SG1 * SCTP Associations | * ******** *
* *_______________________ | * * * *_______________________ | * *
******** | | ************** ******** | | **************
| | | |
******** | | ******** | |
skipping to change at page 6, line 28 skipping to change at page 6, line 28
******** | | ************** ******** | | **************
| |_________________* ******** * Host2 | |_________________* ******** * Host2
|____________________________* * ASP1 * * |____________________________* * ASP1 * *
* ******** * * ******** *
* * * *
************** **************
. .
. .
. .
Figure 2 - Physical Model Example Figure 2 - Logical Model Example
For carrier grade networks, Operators SHOULD ensure that under failure For carrier grade networks, Operators SHOULD ensure that under failure
or isolation of a particular ASP, stable calls or transactions are not or isolation of a particular ASP, stable calls or transactions are not
lost. This implies that ASPs need, in some cases, to share the call/- lost. This implies that ASPs need, in some cases, to share the call/-
transaction state or be able to pass the call/transaction state between transaction state or be able to pass the call/transaction state between
each other. Also, in the case of ASPs performing call processing, each other. Also, in the case of ASPs performing call processing,
coordination MAY be required with the related Media Gateway to transfer coordination MAY be required with the related Media Gateway to transfer
the MGC control for a particular trunk termination. However, this the MGC control for a particular trunk termination. However, this
sharing or communication is outside the scope of this document. sharing or communication is outside the scope of this document.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
The fail-over model supports an n+k redundancy model, where n ASPs The fail-over model supports an n+k redundancy model, where n ASPs
is the minimum number of redundant ASPs required to handle traffic and is the minimum number of redundant ASPs required to handle traffic and
k ASPs are available to take over for a failed or unavailable ASP. k ASPs are available to take over for a failed or unavailable ASP.
Note that 1+1 active/standby redundancy is a subset of this model. Note that 1+1 active/standby redundancy is a subset of this model.
A simplex 1+0 model is also supported as a subset, with no ASP A simplex 1+0 model is also supported as a subset, with no ASP
redundancy. redundancy.
To avoid a single point of failure, it is recommended that a minimum of To avoid a single point of failure, it is recommended that a minimum of
two ASPs be in the list, resident in separate hosts and therefore two ASPs be in the list, resident in separate hosts and therefore
available over different SCTP Associations. For example, in the available over different SCTP Associations. For example, in the
network shown in Figure 2, all messages to DPC x could be sent to ASP1 network shown in Figure 2, all messages for the Interface Identifiers
in Host1 or ASP1 in Host2. The AS list at SG1 might look like this: could be sent to ASP1 in Host1 or ASP1 in Host2. The AS list at SG1
might look like the following:
Interface Identiers - Application Server #1 Interface Identiers - Application Server #1
ASP1/Host1 - State = Active ASP1/Host1 - State = Active
ASP1/Host2 - State = Inactive ASP1/Host2 - State = Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP1 in Host2 would message for the Interface Identifiers registered. ASP1 in Host2 would
normally be brought to the active state upon failure of, or loss of normally be brought to the active state upon failure of, or loss of
connectivity to, ASP1/Host1. In this example, both ASPs are Inactive connectivity to, ASP1/Host1. In this example, both ASPs are Inactive
or Active, meaning that the related SCTP association and far-end M2UA or Active, meaning that the related SCTP association and far-end M2UA
peer is ready. peer is ready.
In the process of fail-over or fail-back, it is recommended that in the The two ASPs MAY share state information via shared memory, or MAY
case of ASPs supporting call processing, stable calls do not get released. use an ASP to ASP protocol to pass state information. The ASP to ASP
It is possible that calls in transition MAY fail, although measures of
communication between the ASPs involved can be used to mitigate this.
For example, the two ASPs MAY share call state via shared memory, or MAY
use an ASP to ASP protocol to pass call state information. The ASP to ASP
protocol is outside the scope of this document. protocol is outside the scope of this document.
1.3.5 Client/Server Model 1.3.5 Client/Server Model
It is recommended that the SG and ASP be able to support both client It is recommended that the SG and ASP be able to support both client
and server operation. The peer endpoints using M2UA SHOULD be and server operation. The peer endpoints using M2UA SHOULD be
configured so that one always takes on the role of client and the configured so that one always takes on the role of client and the
other the role of server for initiating SCTP associations. The other the role of server for initiating SCTP associations. The
default orientation would be for the SG to take on the role of server default orientation would be for the SG to take on the role of server
while the ASP is the client. In this case, ASPs SHOULD initiate the while the ASP is the client. In this case, ASPs SHOULD initiate the
skipping to change at page 7, line 54 skipping to change at page 7, line 51
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required to point in the IP network, so that the M2UA protocol layer is required to
provide the equivalent set of services to its users as provided by the provide the equivalent set of services to its users as provided by the
MTP Level 2 to MTP Level 3. MTP Level 2 to MTP Level 3.
This includes the following services: This includes the following services:
1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary
Also provision is made for protocol elements that enable a seamless, or M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables
as seamless as possible, operation of the MTP2-User peers in the SS7 and a seamless, or as seamless as possible, operation of the MTP2-User peers
IP domains. This includes in the SS7 and IP domains. An example of the primitives that must be
supported can be found in [7].
Data
Provides the ability to transport MTP2 User information (in this case,
MTP Level 3 PDUs).
Link Establish
Provides the ability to request MTP Level 2 to bring SS7 links
in-service.
Link Release
Provides the ability to request MTP Level 2 to take SS7 links out-of-
service. Also, provides mechanism for MTP2 to autonomously indicate
that SS7 link(s) have gone out-of-service.
Link State
Provides the ability to request state change or information on a
per link basis. Some examples would be the forcing of Local Processor
Outage or flushing buffers.
Link Status
Provides a means for asynchronous notification of link state changes to
be reported to the upper layer (MTP Level 3). An example would be the
reporting of remote processor outage event.
Data Retrieval
Provides a mechanism to perform SS7 link changeover procedure in
the case of a SS7 link failure.
1.4.2 Support for communication between Layer Management modules 1.4.2 Support for communication between Layer Management modules
on SG and MGC on SG and MGC
It is envisioned that the M2UA layer needs to provide some messages that It is envisioned that the M2UA layer needs to provide some messages that
will facilitate communication between Layer Management modules on the SG will facilitate communication between Layer Management modules on the SG
and MGC. These primitives are shown below: and MGC. These primitives are shown below:
To facilitate reporting of errors that arise because of backhauling MTP To facilitate reporting of errors that arise because of backhauling MTP
Level 3 scenario, the following primitive is defined: Level 3 scenario, the following primitive is defined:
skipping to change at page 8, line 69 skipping to change at page 8, line 41
The M-SCTP ESTABLISH primitive is used to request, indicate and confirm The M-SCTP ESTABLISH primitive is used to request, indicate and confirm
the establishment of a SCTP association to a peer M2UA node. the establishment of a SCTP association to a peer M2UA node.
M-SCTP RELEASE M-SCTP RELEASE
The M-SCTP RELEASE primitives are used to request, indicate, and The M-SCTP RELEASE primitives are used to request, indicate, and
confirm the release of a SCTP association to a peer M2UA node. confirm the release of a SCTP association to a peer M2UA node.
The M2UA layer MAY also need to inform the status of the SCTP The M2UA layer MAY also need to inform the status of the SCTP
associations to the Layer Management. This can be achieved using
the M-SCTP STATUS primitive.
The M2UA layer MAY also need to inform the status of the SCTP
association(s) to the Layer Management. This can be achieved using association(s) to the Layer Management. This can be achieved using
the following primitive. the following primitive.
M-SCTP STATUS M-SCTP STATUS
The M-SCTP STATUS primitive is used to request and indicate the status The M-SCTP STATUS primitive is used to request and indicate the status
of underlying SCTP association(s). of underlying SCTP association(s).
The Layer Management MAY need to inform the M2UA layer of an AS/ASP The Layer Management MAY need to inform the M2UA layer of an AS/ASP
status (i.e., failure, active, etc.), so that messages can be exchanged status (i.e., failure, active, etc.), so that messages can be exchanged
skipping to change at page 9, line 70 skipping to change at page 9, line 70
/ / +----+ act+-----+ +-------+ -+--+-|+--+- / / +----+ act+-----+ +-------+ -+--+-|+--+-
SS7 link1-------->|IID |-+ +-->| ASP |--->| Assoc | v SS7 link1-------->|IID |-+ +-->| ASP |--->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+--+- / +----+ | +----+ | +-----+ +-------+ -+--+--+--+-
/ +->| AS |--+ Streams / +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+ / +----+ | +----+ stb+-----+
SS7 link2-------->|IID |-+ | ASP | SS7 link2-------->|IID |-+ | ASP |
+----+ +-----+ +----+ +-----+
where IID = Interface Identifier where IID = Interface Identifier
Note that an ASP can be in more than one AS.
1.5.2 Status of ASPs 1.5.2 Status of ASPs
The M2UA layer on the SG MUST maintain the state of the ASPs it is The M2UA layer on the SG MUST maintain the state of the ASPs it is
supporting. The state of an ASP changes because of reception of supporting. The state of an ASP changes because of reception of
peer-to-peer messages (ASPM messages as described in Section 3.3.2) peer-to-peer messages (ASPM messages as described in Section 3.3.2)
or reception of indications from the local SCTP association. ASP or reception of indications from the local SCTP association. ASP
state transition procedures are described in Section 4.3.1. state transition procedures are described in Section 4.3.1.
At a SG, an Application Server list MAY contain active and inactive At a SG, an Application Server list MAY contain active and inactive
ASPs to support ASP fail-over procedures. When, for example, both ASPs to support ASP fail-over procedures. When, for example, both
skipping to change at page 10, line 13 skipping to change at page 10, line 13
taken are implementation dependent. taken are implementation dependent.
1.6 Definition of the M2UA Boundaries 1.6 Definition of the M2UA Boundaries
1.6.1 Definition of the M2UA / MTP Level 3 boundary 1.6.1 Definition of the M2UA / MTP Level 3 boundary
DATA DATA
ESTABLISH ESTABLISH
RELEASE RELEASE
STATE STATE
STATUS
RETRIEVAL
DATA RETRIEVAL DATA RETRIEVAL
DATA RETRIEVAL COMPLETE DATA RETRIEVAL COMPLETE
1.6.2 Definition of the M2UA / MTP Level 2 boundary 1.6.2 Definition of the M2UA / MTP Level 2 boundary
DATA DATA
ESTABLISH ESTABLISH
RELEASE RELEASE
STATE STATE
STATUS
RETRIEVAL
DATA RETRIEVAL DATA RETRIEVAL
DATA RETRIEVAL COMPLETE DATA RETRIEVAL COMPLETE
1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP
The upper layer and layer management primitives provided by SCTP are The upper layer and layer management primitives provided by SCTP are
provided in Reference [5] Section 9. provided in Reference [5] Section 9.
1.6.4 Definition of Layer Management / M2UA Boundary 1.6.4 Definition of Layer Management / M2UA Boundary
skipping to change at page 11, line 40 skipping to change at page 11, line 40
Value Version Value Version
----- ------- ----- -------
1 Release 1.0 1 Release 1.0
3.1.2 Message Type 3.1.2 Message Type
The following List contains the valid Message Classes: The following List contains the valid Message Classes:
Message Class: 8 bits (unsigned integer) Message Class: 8 bits (unsigned integer)
0 Management (MGMT) Message 0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
1 Reserved 1 Transfer Messages [M3UA]
2 Reserved 2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
3 ASP State Maintenance (ASPSM) Messages 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
4 ASP Traffic Maintenance (ASPTM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
5 Reserved 5 Q.921/Q.931 Boundary Primitives Tranport (QPTM)
6 MTP2 User Adaptation (MAUP) Messages Messages [IUA]
Messages 6 MTP2 User Adaptatation (MAUP) Messages [M2UA]
7 to 255 Reserved 7 Connectionless Messages [SUA]
8 Connection-Oriented Messages [SUA]
9 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions
The following list contains the message types for the defined messages. The following list contains the message types for the defined messages.
MTP2 User Adaptatation (MAUP) Messages MTP2 User Adaptatation (MAUP) Messages
0 Reserved 0 Reserved
1 Data 1 Data
2 Establish Request 2 Establish Request
3 Establish Confirm 3 Establish Confirm
4 Release Request 4 Release Request
5 Release Confirm 5 Release Confirm
6 Release Indication 6 Release Indication
7 State Request 7 State Request
8 State Confirm 8 State Confirm
9 State Indication 9 State Indication
10 Data Retrieval Request 10 Data Retrieval Request
11 Data Retrieval Confirm 11 Data Retrieval Confirm
12 Data Retrieval Indication 12 Data Retrieval Indication
13 Data Retrieval Complete Indication 13 Data Retrieval Complete Indication
14 to 255 Reserved for MAUP Messages 14 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MAUP extensions
Application Server Process State Maintenance (ASPSM) messages Application Server Process State Maintenance (ASPSM) messages
0 Reserved 0 Reserved
1 ASP Up (UP) 1 ASP Up (UP)
2 ASP Down (DOWN) 2 ASP Down (DOWN)
3 Heartbeat (BEAT) 3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK) 4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK) 5 ASP Down Ack (DOWN ACK)
6 Heatbeat Ack (BEAT ACK) 6 Heatbeat Ack (BEAT ACK)
7 to 255 Reserved for ASPSM Messages 7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
Application Server Process Traffic Maintenance (ASTM) messages Application Server Process Traffic Maintenance (ASTM) messages
0 Reserved 0 Reserved
1 ASP Active (ACTIVE) 1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE) 2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK) 3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK) 4 ASP Inactive Ack (INACTIVE ACK)
5 to 255 Reserved for ASPTM Messages 5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASTM extensions
Management (MGMT) Messages Management (MGMT) Messages
0 Error (ERR) 0 Error (ERR)
1 Notify (NTFY) 1 Notify (NTFY)
2 to 255 Reserved for Management Messages 2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions
3.1.3 Reserved 3.1.3 Reserved
The Reserved field is 8-bits. It SHOULD be set to all '0's and The Reserved field is 8-bits. It SHOULD be set to all '0's and
ignored by the receiver. ignored by the receiver.
3.1.4 Message Length 3.1.4 Message Length
The Message length defines the length of the message in octets, The Message length defines the length of the message in octets,
including the header. including the header.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
3.3.1.1 Data 3.3.1.1 Data
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The
Data message contains the protocol data. Data message contains the protocol data.
The format for the Data Message parameters is as follows: The format for the Data Message parameters is as follows:
0 1 2 3 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 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 (0xe) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data | | Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in The Protocol Data field contains the MTP2-User application message in
network byte order starting with the Signaling Information Octet (SIO). network byte order starting with the Signaling Information Octet (SIO).
3.3.1.2 Establish (Request, Confirmation) 3.3.1.2 Establish (Request, Confirmation)
The Establish Request message is used to establish the link or to The Establish Request message is used to establish the link or to
indicate that the channel has been established. The MGC controls the state of the indicate that the channel has been established. The MGC controls the
SS7 link. When the MGC desires the SS7 link to be in-service, state of the SS7 link. When the MGC desires the SS7 link to be
it will send the Establish Request message. Note that the gateway in-service, it will send the Establish Request message. Note that the
MAY already have the SS7 link established at its layer. If so, upon gateway MAY already have the SS7 link established at its layer. If so,
receipt of an Establish Request, the gateway takes no action except to upon receipt of an Establish Request, the gateway takes no action except
send an Establish Confirm. to send an Establish Confirm.
When the MGC sends an M2UA Establish Request message, the MGC MAY When the MGC sends an M2UA Establish Request message, the MGC MAY
start a timer. This timer would be stopped upon receipt of an M2UA start a timer. This timer would be stopped upon receipt of an M2UA
Establish Confirm. If the timer expires, the MGC would re-send the Establish Confirm. If the timer expires, the MGC would re-send the
M2UA Establish Request message and restart the timer. In other words, M2UA Establish Request message and restart the timer. In other words,
the MGC MAY continue to request the establishment of the data link the MGC MAY continue to request the establishment of the data link
on periodic basis until the desired state is achieved or take some on periodic basis until the desired state is achieved or take some
other action (notify the Management Layer). other action (notify the Management Layer).
The mode (Normal of Emergency) for bringing the link in service is The mode (Normal of Emergency) for bringing the link in service is
defaulted to Normal. The State Request (described in Section 3.3.1.4 defaulted to Normal. The State Request (described in Section 3.3.1.4
below) can be used to change the mode to Emergency. below) can be used to change the mode to Emergency.
3.3.1.3 Release (Request, Indication, Confirmation) 3.3.1.3 Release (Request, Indication, Confirmation)
This Release Request message is used to release the channel. The This Release Request message is used to release the channel. The
Release Confirm and Indication messages are used to indicate that the Release Confirm and Indication messages are used to indicate that the
channel has been released. channel has been released.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Reason are shown in the following table.
Define Value Description
RELEASE_MGMT 0x0 Management layer generated release
RELEASE_PHYS 0x1 Physical layer alarm generated release
RELEASE_SIOS 0x2 Receipt of SIOS
RELEASE_T6 0x3 Release due to expiration of Timer T6
RELEASE_T7 0x4 Release due to expiration of Timer T7
RELEASE_BSN 0x5 Release due to invalid BSN (2 of 3)
RELEASE_FIB 0x6 Release due to invalid FIB (2 of 3)
RELEASE_SUERM 0x7 Release due to failure reported by SUERM
RELEASE_IAC 0x8 Release due to initial alignment failed
RELEASE_OTHER 0x9 Other reason SS7 link out-of-service
For the Release Request, the only valid Reason is RELEASE_MGMT. For
Release Confirm, the Reason field would also be RELEASE_MGMT (a
reflection of Release Request). The other valid values for Reason
would be used for Release Indication.
3.3.1.4 State (Request, Confirm) 3.3.1.4 State (Request, Confirm)
The State Request message can be sent from a MGC to cause an action The State Request message can be sent from a MGC to cause an action
on a particular SS7 link supported by the Signaling Gateway. The on a particular SS7 link supported by the Signaling Gateway. The
gateway sends a State Confirm to the MGC if the action has been success- gateway sends a State Confirm to the MGC if the action has been success-
fully completed. The State Confirm reflects that state value received fully completed. The State Confirm reflects that state value received
in the State Request message. in the State Request message.
0 1 2 3 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 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 (0x10) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Define Value Description Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered recovered
STATUS_EMER_SET 0x2 Request emergency alignment STATUS_EMER_SET 0x2 Request emergency alignment
skipping to change at page 14, line 33 skipping to change at page 14, line 35
STATUS_CONTINUE 0x5 Continue STATUS_CONTINUE 0x5 Continue
3.3.1.5 State Indication 3.3.1.5 State Indication
The MTP2 State Indication message can be sent from a gateway to an The MTP2 State Indication message can be sent from a gateway to an
ASP to indicate a condition on a link. ASP to indicate a condition on a link.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x15) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cong Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for Event are shown in the following table.
Define Value Description Define Value Description
EVENT_ENTER_LPO 0x0 Entered local processor outage EVENT_CONG_ENTER 0x1 Link Congestion Entered
EVENT_EXIT_LPO 0x1 Exited local processor outage EVENT_CONG_EXIT 0x2 Link Congestion Exited
EVENT_ENTER_CONG 0x2 Entered a congested state EVENT_RPO_ENTER 0x3 Remote entered processor outage
EVENT_EXIT_CONG 0x3 Exited a congested state EVENT_RPO_EXIT 0x4 Remote exited processor outage
EVENT_PHYS_UP 0x4 Physical interface up
EVENT_PHYS_DOWN 0x5 Physical interface down The Cong Level parameter would only be used with a link congestion
EVENT_PROTOCOL_ERR 0x6 Protocol error occurred event. The Cong Level parameter would be used for National Networks
EVENT_REM_ENTER_CONG 0xc Remote entered congestion that make use of multiple congestion levels [2].
EVENT_REM_EXIT_CONG 0xd Remote exited congestion
EVENT_REM_ENTER_PO 0xe Remote entered processor outage
EVENT_REM_EXIT_PO 0xf Remote exited processor outage
3.3.1.6 Retrieval (Request, Confirm) 3.3.1.6 Retrieval (Request, Confirm)
The MTP2 Retrieval Request message is used during the MTP Level 3 The MTP2 Retrieval Request message is used during the MTP Level 3
changeover procedure to request the BSN, to retrieve PDUs from the changeover procedure to request the BSN, to retrieve PDUs from the
retransmit queue or to flush PDUs from the retransmit queue. retransmit queue or to flush PDUs from the retransmit queue.
0 1 2 3 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 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 (0x12) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fsn_bsn | | Tag (0x13) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seq_num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are shown in the following table. The valid values for Action are shown in the following table.
Define Value Description Define Value Description
ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number
ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit
queue queue
ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue
In the Retrieval Request message, the fsn_bsn field SHOULD be ignored if In the Retrieval Request message, the seq_num field SHOULD be ignored if
the Action field is ACTION_RTRV_BSN or ACTION_DROP_MSGS. The fsn_bsn the Action field is ACTION_RTRV_BSN or ACTION_DROP_MSGS. The seq_num
field contains the FSN of the far end if the Action is ACTION_RTRV_MSGS. field contains the Forward Sequnce Number (FSN) of the far end if the
Action is ACTION_RTRV_MSGS.
When the Signaling Gateway sends a Retrieval Confirm to this request, When the Signaling Gateway sends a Retrieval Confirm to this request,
it echos the action and puts the BSN in the fsn_bsn field if the action it echos the action and puts the Backward Sequence Number (BSN) in the
was ACTION_RTRV_BSN. If there is a failure in retrieving the BSN, the seq_num field if the action was ACTION_RTRV_BSN. If there is a failure
fsn_bsn SHOULD contain a -1 (0xffffffff). For a Retrieval Confirm with in retrieving the BSN, the seq_num SHOULD contain a -1 (0xffffffff).
Action of ACTION_RTRV_MSGS or ACTION_DROP_MSGS, the value received in For a Retrieval Confirm with Action of ACTION_RTRV_MSGS, the value of
the fsn_bsn field in the Request message will be sent. of seq_num will be set to zero for success or -1 (0xffffffff) for failure.
A failure means that the buffers could not be retrieved. For a Retrieval
Confirm with an Action of ACTION_DROP_MSGS, the value received in the
seq_num field will be ignored.
3.3.1.7 Retrieval Indication 3.3.1.7 Retrieval Indication
The Retrieval Indication message is sent by the Signaling Gateway The Retrieval Indication message is sent by the Signaling Gateway
with a PDU from the retransmit queue. The Retrieval Indication with a PDU from the retransmit queue. The Retrieval Indication
message does not contain the Action or fsn_bsn fields, just a MTP3 message does not contain the Action or seq_num fields, just a MTP3
Protocol Data Unit (PDU) from the retransmit queue. Protocol Data Unit (PDU) from the retransmit queue.
The M2UA implementation MAY consider the use of the bundling feature
of SCTP for Retrieval Indication messages.
0 1 2 3 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 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 (0x14) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU from retransmit queue | | PDU from retransmit queue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.1.8 Retrieval Complete Indication 3.3.1.8 Retrieval Complete Indication
The MTP2 Retrieval Complete Indication message is exactly the same as The MTP2 Retrieval Complete Indication message is exactly the same as
the MTP2 Retrieval Indication message except that it also indicates that the MTP2 Retrieval Indication message except that it also indicates that
it contains the last PDU from the retransmit queue. it contains the last PDU from the retransmit queue.
skipping to change at page 17, line 19 skipping to change at page 17, line 19
The ASPUP Ack message contains the following parameters: The ASPUP Ack message contains the following parameters:
INFO String (optional) INFO String (optional)
The format for ASPUP Ack Message parameters is as follows: The format for ASPUP Ack Message parameters is as follows:
0 1 2 3 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 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 (0x2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Layer Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
same as for the ASP UP message (See Section 3.3.2.1.) same as for the ASP UP message (See Section 3.3.2.1.)
skipping to change at page 17, line 51 skipping to change at page 17, line 45
The ASPDN message contains the following parameters The ASPDN message contains the following parameters
Reason Reason
INFO String (Optional) INFO String (Optional)
The format for the ASPDN message parameters is as follows: The format for the ASPDN message parameters is as follows:
0 1 2 3 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 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 (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
same as for the ASP Up message (See Section 3.3.2.1.) same as for the ASP Up message (See Section 3.3.2.1.).
The Reason parameter indicates the reason that the remote M2UA The Reason parameter indicates the reason that the remote M2UA
adaptation layer is unavailable. The valid values for Reason are shown adaptation layer is unavailable. The valid values for Reason are shown
in the following table. in the following table.
Value Description Value Description
0x1 Management 0x1 Management
3.3.2.4 ASP Down Ack 3.3.2.4 ASP Down Ack
skipping to change at page 17, line 85 skipping to change at page 17, line 81
The ASP Down Ack message contains the following parameters: The ASP Down Ack message contains the following parameters:
Reason Reason
INFO String (Optional) INFO String (Optional)
The format for the ASPDN Ack message parameters is as follows: The format for the ASPDN Ack message parameters is as follows:
0 1 2 3 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 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 (0xa) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
skipping to change at page 17, line 119 skipping to change at page 17, line 117
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (Optional)
The format for the ASPAC message using integer formatted Interface The format for the ASPAC message using integer formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length | | Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* | | Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length | | Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 163 skipping to change at page 17, line 163
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASPAC message using text formatted (string) The format for the ASPAC message using text formatted (string)
Interface Identifiers is as follows: Interface Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length | | Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | Additional Interface Identifiers |
skipping to change at page 19, line ? skipping to change at page 19, line ?
Interface Identifier integers (Type 0x1 or Type 0x8) or text strings Interface Identifier integers (Type 0x1 or Type 0x8) or text strings
(Type 0x3)indexing the Application Server traffic that the sending (Type 0x3)indexing the Application Server traffic that the sending
ASP is configured/registered to receive. If integer formatted ASP is configured/registered to receive. If integer formatted
Interface Identifiers are being used, the ASP can also send ranges of Interface Identifiers are being used, the ASP can also send ranges of
Interface Identifiers (Type 0x8). Interface Identifier types Integer Interface Identifiers (Type 0x8). Interface Identifier types Integer
(0x1) and Integer Range (0x8) are allowed in the same message. Text (0x1) and Integer Range (0x8) are allowed in the same message. Text
formatted Interface Identifiers (0x3) cannot be used with either formatted Interface Identifiers (0x3) cannot be used with either
Integer (0x1) or Integer Range (0x8) types. Integer (0x1) or Integer Range (0x8) types.
If no Interface Identifiers are included, the message is for all If no Interface Identifiers are included, the message is for all
provisioned Interface Identifiers within the AS. If only a subset provisioned Interface Identifiers within the AS(s) in which the
of Interface Identifiers are includes, the ASP is noted as Active ASP is provisioned. If only a subset of Interface Identifiers are
for all the Interface Identifiers provisioned for the AS. included, the ASP is noted as Active for all the Interface Identifiers
provisioned for that AS.
Note: If the optional Interface Identifier parameter is present, the Note: If the optional Interface Identifier parameter is present, the
integer formatted Interface Identifier MUST be supported, while the integer formatted Interface Identifier MUST be supported, while the
text formatted Interface Identifier MAY be supported. text formatted Interface Identifier MAY be supported.
An SG that receives an ASPAC with an incorrect Traffic Mode Type for An SG that receives an ASPAC with an incorrect Traffic Mode Type for
a particular Interface Identifier will respond with an Error Message a particular Interface Identifier will respond with an Error Message
(Cause: Unsupported Traffic Handling Mode). (Cause: Unsupported Traffic Handling Mode).
The format and description of the optional Info String parameter is the The format and description of the optional Info String parameter is the
skipping to change at page 19, line ? skipping to change at page 19, line ?
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (Optional)
The format for the ASPAC Ack message with Integer-formatted Interface The format for the ASPAC Ack message with Integer-formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length | | Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* | | Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length | | Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line ? skipping to change at page 19, line ?
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Active Ack message using text formatted (string) The format for the ASP Active Ack message using text formatted (string)
Interface Identifiers is as follows: Interface Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length | | Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | Additional Interface Identifiers |
skipping to change at page 19, line ? skipping to change at page 19, line ?
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (Optional)
The format for the ASP Inactive message parameters using Integer The format for the ASP Inactive message parameters using Integer
formatted Interface Identifiers is as follows: formatted Interface Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length | | Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* | | Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length | | Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line ? skipping to change at page 19, line ?
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Inactive message using text formatted (string) The format for the ASP Inactive message using text formatted (string)
Interface Identifiers is as follows: Interface Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length | | Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | Additional Interface Identifiers |
skipping to change at page 19, line ? skipping to change at page 19, line ?
Interface Identifiers (Optional) Interface Identifiers (Optional)
- Combination of integer and integer ranges, OR - Combination of integer and integer ranges, OR
- string (text formatted) - string (text formatted)
INFO String (Optional) INFO String (Optional)
The format for the ASPIA Ack message is as follows: The format for the ASPIA Ack message is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length | | Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* | | Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length | | Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line ? skipping to change at page 19, line ?
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the ASP Inactive Ack message using text formatted The format for the ASP Inactive Ack message using text formatted
(string) Interface Identifiers is as follows: (string) Interface Identifiers is as follows:
0 1 2 3 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 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length | | Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | Additional Interface Identifiers |
skipping to change at page 19, line ? skipping to change at page 19, line ?
The ERR message contains the following parameters: The ERR message contains the following parameters:
Error Code Error Code
Diagnostic Information (optional) Diagnostic Information (optional)
The format for the ERR message is as follows: The format for the ERR message is as follows:
0 1 2 3 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 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 (0xc) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x7) | Length | | Tag (0x7) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diagnostic Information* | | Diagnostic Information* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error Message. The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values: The Error parameter value can be one of the following values:
Invalid Version 0x1 Invalid Version 0x1
Invalid Interface Identifier 0x2 Invalid Interface Identifier 0x2
Invalid Adaptation Layer Identifier 0x3 Unsupported Message Class 0x3
Invalid Message Type 0x4 Unsupported Message Type 0x4
Unsupported Traffic Handling Mode 0x5 Unsupported Traffic Handling Mode 0x5
Unexpected Message 0x6 Unexpected Message 0x6
Protocol Error 0x7 Protocol Error 0x7
Invalid Stream Identifier 0x8 Invalid Stream Identifier 0x8
Unsupported Interface Identifier Type 0x9
The "Invalid Version" error would be sent if a message was The "Invalid Version" error would be sent if a message was
received with an invalid or unsupported version. The Error message received with an invalid or unsupported version. The Error message
would contain the supported version in the Common header. The would contain the supported version in the Common header. The
Error message could optionally provide the supported version in Error message could optionally provide the supported version in
the Diagnostic Information area. the Diagnostic Information area.
The "Invalid Interface Identifier" error would be sent by a SG if The "Invalid Interface Identifier" error would be sent by a SG if
an ASP sends a message with an invalid (unconfigured) Interface an ASP sends a message with an invalid (unconfigured) Interface
Identifier value. Identifier value.
skipping to change at page 19, line ? skipping to change at page 19, line ?
Mode. An example would be a case in which the SG did not support Mode. An example would be a case in which the SG did not support
load-sharing. load-sharing.
The "Unexpected Message" error would be sent by an ASP if it received The "Unexpected Message" error would be sent by an ASP if it received
a MAUP message from an SG while it was in the Inactive state. a MAUP message from an SG while it was in the Inactive state.
The "Protocol Error" error would be sent for any protocol anomaly The "Protocol Error" error would be sent for any protocol anomaly
(i.e. a bogus message). (i.e. a bogus message).
The "Invalid Stream Identifier" error would be sent if a message The "Invalid Stream Identifier" error would be sent if a message
was received on an unexpected SCTP stream (i.e. a stream that did was received on an unexpected SCTP stream (i.e. i.e. a MGMT message
not have an Interface Identifier associated with it). was received on a stream other than "0").).
The "Unsupported Interface Identifier Type" error would be sent by
a SG if an ASP sends a Text formatted Interface Identifier and the
SG only supports Integer formatted Interface Identifiers. When
the ASP receives this error, it will need to resend its message with
an Integer formatted Interface Identifier.
The "Unsupported Message Class" error would be sent if a message with
an unexpected or unsupported Message Class is received.
The "Unsupported Interface Identifier Type" error would be sent by The "Unsupported Interface Identifier Type" error would be sent by
a SG if an ASP sends a Text formatted Interface Identifier and the a SG if an ASP sends a Text formatted Interface Identifier and the
SG only supports Integer formatted Interface Identifiers. When SG only supports Integer formatted Interface Identifiers. When
the ASP receives this error, it will need to resend its message with the ASP receives this error, it will need to resend its message with
an Integer formatted Interface Identifier. an Integer formatted Interface Identifier.
The optional Diagnostic information can be any information germain to The optional Diagnostic information can be any information germain to
the error condition, to assist in identification of the error condition. the error condition, to assist in identification of the error condition.
In the case of an Invalid Version Error Code the Diagnostic information In the case of an Invalid Version Error Code the Diagnostic information
skipping to change at page 20, line 23 skipping to change at page 20, line 23
Status Identification Status Identification
Interface Identifiers (Optional) Interface Identifiers (Optional)
INFO String (Optional) INFO String (Optional)
The format for the Notify message with Integer-formatted Interface The format for the Notify message with Integer-formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 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 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 (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification | | Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length | | Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* | | Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length | | Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 67 skipping to change at page 20, line 69
| INFO String* | | INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for the Notify message with Text-formatted Interface The format for the Notify message with Text-formatted Interface
Identifiers is as follows: Identifiers is as follows:
0 1 2 3 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 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 (0xd) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification | | Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length | | Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Interface Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Interface Identifiers | | Additional Interface Identifiers |
skipping to change at page 24, line 356 skipping to change at page 24, line 356
- Send the MAUP message to the remote M2UA peer in the ASP, over the - Send the MAUP message to the remote M2UA peer in the ASP, over the
SCTP association SCTP association
5.3.1 SS7 Link Alignment 5.3.1 SS7 Link Alignment
The MGC can request that a SS7 link be brought into alignment using the The MGC can request that a SS7 link be brought into alignment using the
normal or emergency procedure. An example of the message flow to bring normal or emergency procedure. An example of the message flow to bring
a SS7 link in-service using the normal alignment procedure is shown a SS7 link in-service using the normal alignment procedure is shown
below. below.
SG ASP MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|<---------Establish Req--------------|
| | <----Start Req---|<---Establish Req----|<----Start Req------
|----------Establish Cfm------------->|
| | ---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind---->
An example of the message flow to bring a SS7 link in-service using the An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure. emergency alignment procedure.
SG ASP MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|<----State Req (STATUS_EMER_SET)-----|
| | <----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req---
|-----State Cfm (STATUS_EMER_SET)---->|
| | -----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm---->
|<---------Establish Req--------------|
| | <---Start Req----|<-------Establish Req-------------|<---Start Req----
|----------Establish Cfm------------->|
| | ---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind-->
5.3.2 SS7 Link Release 5.3.2 SS7 Link Release
The MGC can request that a SS7 link be taken out-of-service. It uses The MGC can request that a SS7 link be taken out-of-service. It uses
the Release Request message as shown below. the Release Request message as shown below.
SG ASP MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|<-----Release Req (RELEASE_MGMT)-----|
| | <-----Stop Req-----|<---Release Req------|<-----Stop Req------
|------------Release Cfm------------->|
| | --Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind-->
The SG can autonomously indicate that a SS7 link has gone out-of-service The SG can autonomously indicate that a SS7 link has gone out-of-service
as shown below. as shown below.
SG ASP MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|------Release Ind (RELEASE_PHYS)---->|
| | --Out of Serv->|----Release Ind----->|--Out of Serv-->
5.3.3 Set and Clear Local Processor Outage 5.3.3 Set and Clear Local Processor Outage
The MGC can set a Local Processor Outage condition. It uses the The MGC can set a Local Processor Outage condition. It uses the
State Request message as shown below. State Request message as shown below.
SG ASP MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|<-----State Req (STATUS_LPO_SET)-----|
| | <----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req---
|------State Cfm (STATUS_LPO_SET)---->|
| | -----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm---->
The MGC can clear a Local Processor Outage condition. It uses the The MGC can clear a Local Processor Outage condition. It uses the
State Request message as shown below. State Request message as shown below.
SG ASP MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|<----State Req (STATUS_LPO_CLEAR)----|
| |
|-----State Cfm (STATUS_LPO_CLEAR)--->|
| |
5.3.4 Notification of Processor Outage (local or remote) <---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req---
The SG can indicate a Local or Remote Processor Outage condition. It ----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm---->
uses the State Indication message as shown below.
SG ASP 5.3.4 Notification of Remote Processor Outage
| |
|-----State Ind (EVENT_ENTER_LPO)---->|
| |
|-----State Ind (EVENT_EXIT_LPO)----->|
| |
SG ASP The SG can indicate Remote has entered or exited the Processor Outage
| | condition. It uses the State Indication message as shown below.
|-----State Ind (EVENT_ENTER_RPO)---->|
| |
|-----State Ind (EVENT_EXIT_RPO)----->|
| |
5.3.5 SS7 Link Changeover MTP2 M2UA M2UA MTP3
SG SG ASP ASP
An example of the message flow for a changeover is shown below. In this ----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind---->
example, there were three messages in the retransmission queue that
needed to be retrieved.
SG ASP -RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind-->
| |
|<---Retrieval Req (MTP2_RTRV_BSN)----| 5.3.5 Notification of Link Congestion
| |
|------Retrieval Cfm (with BSN)------>| The SG can indicate that a link has become congested. It uses the State
| | Indication message as shown below.
|<--Retrieval Req (MTP2_RTRV_MSGS)----|
| with FSN | MTP2 M2UA M2UA MTP3
| | SG SG ASP ASP
|-----------Retrieval Cfm------------>|
| | ----Cong Ind---->|--State Ind (EVENT_CONG_ENTER)->|----Cong Ind---->
|-----------Retrieval Ind------------>|
|-----------Retrieval Ind------------>| -Cong Cease Ind->|--State Ind (EVENT_CONG_EXIT)-->|-Cong Cease Ind->
|-------Retrieval Complete Ind------->|
| | 5.3.6 SS7 Link Changeover
An example of the message flow for an error free changeover is shown
below. In this example, there were three messages in the retransmission
queue that needed to be retrieved.
MTP2 M2UA M2UA MTP3
SG SG ASP ASP
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
(seq_num = 0)
-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
(seq_num = BSN)
<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
(seq_num = FSN)
-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
(seq_num = 0)
-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->
-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->
-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->
-Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind-->
Note: The number of Retrieval Indication is dependent on the number of Note: The number of Retrieval Indication is dependent on the number of
messages in the retransmit queue that have been requested. Only one messages in the retransmit queue that have been requested. Only one
Retrieval Complete Indication SHOULD be sent. Retrieval Complete Indication SHOULD be sent.
An example of a message flow with an error retrieving the BSN is shown
below.
MTP2 M2UA M2UA MTP3
SG SG ASP ASP
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
-BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv-->
(seq_num = -1)
An example of a message flow with an error retrieving the messages is
shown below.
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
(seq_num = BSN)
<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
(seq_num = FSN)
-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
(seq_num = -1)
An example of a message flow for a request to drop messages (clear
retransmission buffers) is shown below.
MTP2 M2UA M2UA MTP3
SG SG ASP ASP
<-Clr RTB Req-|<--Rtrv Req (ACTION_DROP_MSGS)--|<--Clr RTB Req---
-Clr RTB Ind->|---Rtrv Cfm (ACTION_DROP_MSGS)->|---Clr RTB Ind-->
5.3.7 Flush and Continue
The following message flow shows a request to flush buffers.
MTP2 M2UA M2UA MTP3
SG SG ASP ASP
<--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req--
---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm-->
The following message flow shows a request to continue.
MTP2 M2UA M2UA MTP3
SG SG ASP ASP
<---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req---
----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm-->
6.0 Security 6.0 Security
M2UA is designed to carry signaling messages for telephony services. As such, M2UA is designed to carry signaling messages for telephony services. As such,
M2UA MUST involve the security needs of several parties: the end users M2UA MUST involve the security needs of several parties: the end users
of the services; the network providers and the applications involved. of the services; the network providers and the applications involved.
Additional requirements MAY come from local regulation. While having some Additional requirements MAY come from local regulation. While having some
overlapping security needs, any security solution SHOULD fulfill all of the overlapping security needs, any security solution SHOULD fulfill all of the
different parties' needs. different parties' needs.
6.1 Threats 6.1 Threats
skipping to change at page 31, line 59 skipping to change at page 31, line 131
M2UA runs on top of SCTP. SCTP [5] provides certain transport related M2UA runs on top of SCTP. SCTP [5] provides certain transport related
security features, such as: security features, such as:
* Blind Denial of Service Attacks * Blind Denial of Service Attacks
* Flooding * Flooding
* Masquerade * Masquerade
* Improper Monopolization of Services * Improper Monopolization of Services
When M2UA is running in professionally managed corporate or service When M2UA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network includes provider network, it is reasonable to expect that this network includes
an appropriate security policy framework. The "Site Security Handbook" [8] an appropriate security policy framework. The "Site Security Handbook" [9]
SHOULD be consulted for guidance. SHOULD be consulted for guidance.
When the network in which M2UA runs in involves more than one party, it When the network in which M2UA runs in involves more than one party, it
MAY NOT be reasonable to expect that all parties have implemented security 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 in a sufficient manner. In such a case, it is recommended that IPSEC is
used to ensure confidentiality of user payload. Consult [9] for more used to ensure confidentiality of user payload. Consult [10] for more
information on configuring IPSEC services. information on configuring IPSEC services.
6.2 Protecting Confidentiality 6.2 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality MAY Particularly for mobile users, the requirement for confidentiality MAY
include the masking of IP addresses and ports. In this case application include the masking of IP addresses and ports. In this case application
level encryption is not sufficient; IPSEC ESP SHOULD be used instead. level encryption is not sufficient; IPSEC ESP SHOULD be used instead.
Regardless of which level performs the encryption, the IPSEC ISAKMP Regardless of which level performs the encryption, the IPSEC ISAKMP
service SHOULD be used for key management. service SHOULD be used for key management.
7.0 IANA Considerations 7.0 IANA Considerations
7.1 SCTP Payload Protocol Identifier
A request will be made to IANA to assign an M2UA value for the Payload A request will be made to IANA to assign an M2UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload
Protocol Identifier will be registered: Protocol Identifier will be registered:
M2UA 0x10 M2UA 0x10
The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, The SCTP Payload Protocol Identifier is included in each SCTP Data chunk,
to indicate which protocol the SCTP is carrying. This Payload Protocol to indicate which protocol the SCTP is carrying. This Payload Protocol
Identifier is not directly used by SCTP but MAY be used by certain network Identifier is not directly used by SCTP but MAY be used by certain network
entities to identify the type of information being carried in a Data chunk. entities to identify the type of information being carried in a Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a way The User Adaptation peer MAY use the Payload Protocol Identifier as a way
of determining additional information about the data being presented to it of determining additional information about the data being presented to it
by SCTP. by SCTP.
7.2 M2UA Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types and parameters is
an integral part of SIGTRAN adaptation layers. Thus, these extensions
are assigned by IANA through an IETF Consensus action as defined in
[RFC2434].
The proposed extension must in no way adversely affect the general
working of the protocol.
7.2.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the message class.
(b) A detailed description of the purpose of the message class.
7.2.2 IETF Defined Message Types
Documentation of the message type MUST contain the following information:
(a) A long and short name for the new message type.
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each field
within the message.
(d) A detailed procedural description of the use of the new message type
within the operation of the protocol.
(e) A detailed description of error conditions when receiving this message
type.
When an implementation receives a message type which it does not support,
it MUST respond with an Error (ERR) message with an Error Code of
Unsupported Message Type.
7.2.3 IETF-defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field. This
structure MUST conform to the general type-length-value format
described in Section 3.1.5.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within the
same message type.
8.0 Acknowledgements 8.0 Acknowledgements
The authors would like to thank John Loughney, Neil Olson, Michael The authors would like to thank John Loughney, Neil Olson, Michael
Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz
Prantner, Barry Nagelberg, Naoto Makinae for their valuable comments Prantner, Barry Nagelberg, Naoto Makinae and Brian Bidulock for their
and suggestions. valuable comments and suggestions.
9.0 References 9.0 References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling
System No. 7 (SS7)' System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) -
Message Transfer Part (MTP)' Message Transfer Part (MTP)'
[3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part' [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
[4] Bellcore GR-246-CORE 'Bell Communications Research Specification [4] Bellcore GR-246-CORE 'Bell Communications Research Specification
of Signaling System Number 7', Volume 1, December 1995 of Signaling System Number 7', Volume 1, December 1995
[5] Stream Control Transmission Protocol, RFC 2960, October 2000 [5] Stream Control Transmission Protocol, RFC 2960, October 2000
[6] Architectural Framework for Signaling Transport, RFC 2719 , [6] Architectural Framework for Signaling Transport, RFC 2719 ,
October 1999 October 1999
[7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 [7] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February
1995
[8] ITU-T Recommendation Q.2210, 'Message transfer part level 3
functions and messages using the services of ITU-T functions and messages using the services of ITU-T
Recommendation Q.2140' Recommendation Q.2140', August 1995
[8] Site Security Handbook, RFC 2196, September 1997 [9] Site Security Handbook, RFC 2196, September 1997
[9] Security Architecture for the Internet Protocol, RFC 2401 [10] Security Architecture for the Internet Protocol, RFC 2401
10.0 Issues To Be Addressed
1. SCTP failure (what does M2UA on SG and MGC do)
2. SCTP congestion (what does M2UA on SG and MGC do)
3. PRI/LI octet for TTC
4. auditing of link state
5. M2UA loses connectivity with MTP2 on SG
a. autonomously sends LPO to MTP3, or
b. sends LPO to MTP3 in response to Release Req (Stop)
6. How to indicate failure to perform State Request
(vs. current method of not sending State Confirm)
7. Use of "high priority" stream for link state
messages (i.e. congestion)
9. Adding text for T(ack) timer for ASP UP message
9. Response in reply to Indication messages?
10.0 Author's Addresses 10.0 Author's Addresses
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Ram Dantu, Ph.D. Tel +1-469-255-0716 Ram Dantu, Ph.D. Tel +1-469-255-0716
 End of changes. 

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