draft-ietf-sigtran-m2pa-04.txt   draft-ietf-sigtran-m2pa-05.txt 
Network Working Group Tom George Network Working Group Tom George
INTERNET-DRAFT Alcatel INTERNET-DRAFT Alcatel
Ram Dantu Ram Dantu
Cisco Systems Netrake
Malleswar Kalla Malleswar Kalla
Telcordia Telcordia
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Greg Sidebottom Greg Sidebottom
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
Brian Bidulock
OpenSS7
Expires August 2002 February 28, 2002 Expires November 2002 May 3, 2002
SS7 MTP2-User Peer-to-Peer Adaptation Layer SS7 MTP2-User Peer-to-Peer Adaptation Layer
<draft-ietf-sigtran-m2pa-04.txt> <draft-ietf-sigtran-m2pa-05.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 8 skipping to change at page 2, line 8
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow '1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This Internet Draft defines a protocol supporting the transport of This Internet Draft defines a protocol supporting the transport of
Signaling System Number 7 (SS7) Message Transfer Part (MTP) Layer 3 Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3
signaling messages over Internet Protocol (IP) using the services of signaling messages over Internet Protocol (IP) using the services of
the Stream Control Transmission Protocol (SCTP). This protocol would the Stream Control Transmission Protocol (SCTP). This protocol would
be used between SS7 Signaling Points employing the MTP Level 3 be used between SS7 Signaling Points using the MTP Level 3
protocol. The SS7 Signaling Points may also employ standard SS7 links protocol. The SS7 Signaling Points may also use standard SS7 links
using the SS7 MTP Layer 2 to provide transport of MTP Layer 3 using the SS7 MTP Level 2 to provide transport of MTP Level 3
signaling messages. signaling messages.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction............................................. 4 1. Introduction............................................. 4
1.1 Scope................................................. 4 1.1 Scope................................................. 4
1.2 Terminology........................................... 4 1.2 Terminology........................................... 4
1.3 Abbreviations......................................... 5 1.3 Abbreviations......................................... 5
1.4 Conventions........................................... 6 1.4 Conventions........................................... 6
1.5 Signaling Transport Architecture...................... 6 1.5 Signaling Transport Architecture...................... 6
1.6 Services Provided by M2PA............................. 9 1.6 Services Provided by M2PA............................. 8
1.7 Functions Provided by M2PA............................10 1.7 Functions Provided by M2PA............................ 9
1.8 Definition of the M2PA Boundaries.....................11 1.8 Definition of the M2PA Boundaries.....................10
1.9 Differences Between M2PA and M2UA.....................12 1.9 Differences Between M2PA and M2UA.....................12
2. Protocol Elements........................................14 2. Protocol Elements........................................14
2.1 Common Message Header.................................14 2.1 Common Message Header.................................14
2.2 M2PA Header...........................................16 2.2 M2PA Header...........................................15
2.3 M2PA Messages.........................................16 2.3 M2PA Messages.........................................16
3. M2PA Link State Control..................................20 3. M2PA Link State Control..................................20
4. Procedures...............................................24 4. Procedures...............................................23
4.1 Procedures to Support MTP2 Features...................24 4.1 Procedures to Support MTP2 Features...................23
4.2 Procedures to Support the MTP3/MTP2 Interface.........33 4.2 Procedures to Support the MTP3/MTP2 Interface.........33
5. Examples of M2PA Procedures..............................37 5. Examples of M2PA Procedures..............................38
5.1 Link Initialization (Alignment).......................38 5.1 Link Initialization (Alignment).......................38
5.2 Message Transmission and Reception....................40 5.2 Message Transmission and Reception....................40
5.3 Link Status Indication................................40 5.3 Link Status Indication................................40
5.4 Link Status Message (Processor Outage)................41 5.4 Link Status Message (Processor Outage)................41
5.5 Level 2 Flow Control..................................42 5.5 Level 2 Flow Control..................................42
5.6 MTP3 Signaling Link Congestion........................43 5.6 MTP3 Signaling Link Congestion........................43
5.7 Link Deactivation.....................................43 5.7 Link Deactivation.....................................43
5.8 Link Changeover.......................................44 5.8 Link Changeover.......................................44
6. Security.................................................45 6. Security.................................................45
6.1 Threats...............................................45 6.1 Threats...............................................45
skipping to change at page 4, line 22 skipping to change at page 4, line 22
- a Signaling Gateway (SG) and a Media Gateway Controller (MGC) - a Signaling Gateway (SG) and a Media Gateway Controller (MGC)
[1] [1]
- a SG and an IP Signaling Point (IPSP) - a SG and an IP Signaling Point (IPSP)
- an IPSP and an IPSP - an IPSP and an IPSP
This could allow for convergence of some signaling and data This could allow for convergence of some signaling and data
networks. SCN signaling nodes would have access to databases and other networks. SCN signaling nodes would have access to databases and other
devices in the IP network domain that do not employ SS7 signaling devices in the IP network domain that do not use SS7 signaling
links. Likewise, IP telephony applications would have access to SS7 links. Likewise, IP telephony applications would have access to SS7
services. There may also be operational cost and performance services. There may also be operational cost and performance
advantages when traditional signaling links are replaced by IP network advantages when traditional signaling links are replaced by IP network
"connections". "connections".
The delivery mechanism described in this document allows for full MTP3 The delivery mechanism described in this document allows for full MTP3
message handling and network management capabilities between any two message handling and network management capabilities between any two
SS7 nodes, communicating over an IP network. An SS7 node equipped with SS7 nodes, communicating over an IP network. An SS7 node equipped with
an IP network connection is called an IP Signaling Point (IPSP). The an IP network connection is called an IP Signaling Point (IPSP). The
IPSPs function as traditional SS7 nodes using the IP network instead IPSPs function as traditional SS7 nodes using the IP network instead
skipping to change at page 8, line 34 skipping to change at page 8, line 27
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| MTP1 | | MTP1 | SCTP | | SCTP | | MTP1 | | MTP1 | SCTP | | SCTP |
| | | +------+ +------+ | | | +------+ +------+
| | | | IP | | IP | | | | | IP | | IP |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
SEP - SS7 Signaling Endpoint SEP - SS7 Signaling Endpoint
Figure 2: M2PA in IP Signaling Gateway Figure 2: M2PA in IP Signaling Gateway
Figure 2 is only an example. Other configurations are possible. For Figure 2 is only an example. Other configurations are possible. In
example, IPSPs without traditional SS7 links could use the protocol short, M2PA uses the SCTP association as an SS7 link. The M2PA/SCTP/IP
layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network with all stack can be used in place of an MTP2/MTP1 stack.
IP links.
Another example, related to Figure 2, is that two SGs could be
connected over an IP network to form an SG mated pair similar to the
way STPs are provisioned in traditional SS7 networks.
1.5.1 Point Code Representation 1.5.1 Point Code Representation
The MTP specification requires that each node with an MTP3 layer is The MTP specification requires that each node with an MTP3 layer is
identified by an SS7 point code. In particular, each IPSP must have identified by an SS7 point code. In particular, each IPSP must have
its own SS7 point code. its own SS7 point code.
1.6 Services Provided by M2PA 1.6 Services Provided by M2PA
The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The
skipping to change at page 10, line 27 skipping to change at page 10, line 5
includes includes
- Data retrieval to support the MTP3 changeover procedure - Data retrieval to support the MTP3 changeover procedure
- Reporting of link status changes to MTP3 - Reporting of link status changes to MTP3
- Processor outage procedure - Processor outage procedure
- Link alignment procedure - Link alignment procedure
SCTP provides reliable, sequenced delivery of messages.
1.7.3 Mapping of SS7 and IP Entities 1.7.3 Mapping of SS7 and IP Entities
The M2PA layer must maintain a map of each of its SS7 links to the The M2PA layer must maintain a map of each of its SS7 links to the
corresponding SCTP association. corresponding SCTP association.
1.7.4 SCTP Stream Management 1.7.4 SCTP Stream Management
SCTP allows a user-specified number of streams to be opened during the SCTP allows a user-specified number of streams to be opened during the
initialization. It is the responsibility of the M2PA layer to ensure initialization. It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association. proper management of the streams allowed within each association.
skipping to change at page 16, line 18 skipping to change at page 16, line 8
including the Common Header. including the Common Header.
2.2 M2PA Header 2.2 M2PA Header
All protocol messages for M2PA require an M2PA-specific header. The All protocol messages for M2PA require an M2PA-specific header. The
header structure is shown in Figure 6. header structure is shown in Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSN | FSN | | unused | BSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | FSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: M2PA-specific Message Header Figure 6: M2PA-specific Message Header
2.2.1 Backward Sequence Number 2.2.1 Backward Sequence Number
This is the FSN of the message last received from the peer. This is the FSN of the message last received from the peer.
2.2.2 Forward Sequence Number 2.2.2 Forward Sequence Number
skipping to change at page 21, line 29 skipping to change at page 21, line 29
| | | | | |
| | MTP3 Start | | | MTP3 Start |
| | | | | |
| V | | V |
| +-----------+ | | +-----------+ |
+<-----------------------| AIP |----------------------->+ +<-----------------------| AIP |----------------------->+
| MTP3 Stop +-----------+ SCTP Comm Error | | MTP3 Stop +-----------+ SCTP Comm Error |
| OR T1 Expiry | OR SCTP Comm Lost | | OR T1 Expiry | OR SCTP Comm Lost |
| | | | | |
| | | | | |
| | Send and |
| | Receive LS Alignment | | | Receive LS Alignment |
| | OR LS Proving |
| | | | | |
| V | | V |
| +-----------+ | | +-----------+ |
+<-----------------------| PROVING |----------------------->+ +<-----------------------| PROVING |----------------------->+
| MTP3 Stop +-----------+ SCTP Comm Error | | MTP3 Stop +-----------+ SCTP Comm Error |
| OR Receive LS OOS | OR SCTP Comm Lost | | OR Receive LS OOS | OR SCTP Comm Lost |
| | | | | |
| | T2 Expiry | | | T2 Expiry |
| | | | | |
| V | | V |
skipping to change at page 22, line 11 skipping to change at page 22, line 11
| | | |
| | | |
| | | |
| | | |
| | | |
| | MTP3 Stop | | MTP3 Stop
| | OR Receive LS OOS | | OR Receive LS OOS
| | OR SCTP Comm Error | | OR SCTP Comm Error
| | OR SCTP Comm Lost | | OR SCTP Comm Lost
| | OR T6 Expiry | | OR T6 Expiry
| | OR M2PA Link Failure
| | | |
| V | V
| +-----------+ | +-----------+
+<-----------------------| RETRIEVAL | +<-----------------------| RETRIEVAL |
Retrieval Complete +-----------+ Retrieval Complete +-----------+
OR MTP3 Start OR MTP3 Start
Figure 7: M2PA Link State Transition Diagram Figure 7: M2PA Link State Transition Diagram
Figure 8 illustrates state changes in the M2PA management of the SCTP Figure 8 illustrates state changes in the M2PA management of the SCTP
skipping to change at page 29, line 31 skipping to change at page 29, line 31
out of service. out of service.
After the association is established, M2PA shall send a Link Status After the association is established, M2PA shall send a Link Status
Out of Service message to its peer. Out of Service message to its peer.
Once the association is established and M2PA has received a Start Once the association is established and M2PA has received a Start
Request from MTP3, M2PA sends the Link Status Alignment message to its Request from MTP3, M2PA sends the Link Status Alignment message to its
peer. If M2PA has not already received the Link Status Alignment peer. If M2PA has not already received the Link Status Alignment
message from its peer, then M2PA starts timer T1. message from its peer, then M2PA starts timer T1.
(Note that if the remote M2PA has not received a Start Request from its (Note that if the remote M2PA has not received a Start Request from
MTP3, it will not send the Link Status Alignment message to the its MTP3, it will not send the Link Status Alignment message to the
local M2PA. Eventually timer T1 in the local M2PA will expire.) local M2PA. Eventually timer T1 in the local M2PA will expire. If the
remote M2PA receives a Start Request from its MTP3 and sends Link
Status Alignment before the local M2PA's timer T1 expires, the
alignment procedure can continue.)
M2PA stops timer T1 when it has received the Link Status Alignment M2PA stops timer T1 when it has received the Link Status Alignment
message from its peer. message from its peer.
If timer T1 expires, then M2PA reports to MTP3 that the link is out of If timer T1 expires, then M2PA reports to MTP3 that the link is out of
service. M2PA sends Link Status Out of Service to its peer. M2PA service. M2PA sends Link Status Out of Service to its peer. M2PA
should leave the association established. M2PA waits for MTP3 to should leave the association established. M2PA waits for MTP3 to
initiate the alignment procedure again. initiate the alignment procedure again.
Note: Between the time M2PA sends Link Status Alignment to its peer Note: Between the time M2PA sends Link Status Alignment to its peer
skipping to change at page 32, line 23 skipping to change at page 32, line 29
messages. messages.
M2PA should periodically send a Link Status Busy message as long as M2PA should periodically send a Link Status Busy message as long as
it is in receive congestion. it is in receive congestion.
M2PA shall continue transmitting messages while it is in receive M2PA shall continue transmitting messages while it is in receive
congestion. congestion.
When the peer M2PA receives the Link Status Busy message, it shall When the peer M2PA receives the Link Status Busy message, it shall
start the Remote Congestion timer T6. If timer T6 expires, M2PA shall start the Remote Congestion timer T6. If timer T6 expires, M2PA shall
take the link out of service. take the link out of service. M2PA sends a Link Status Out of Service
message to its peer, and goes to the Retrieval state.
The peer M2PA shall cease transmitting messages to SCTP while its The peer M2PA shall cease transmitting messages to SCTP while its
T6 timer is running, i.e., while the other end is Busy. T6 timer is running, i.e., while the other end is Busy.
If M2PA is no longer in receive congestion for the association, M2PA If M2PA is no longer in receive congestion for the association, M2PA
shall send a Link Status Busy Ended message to its peer on that shall send a Link Status Busy Ended message to its peer on that
association. association.
When the peer M2PA receives the Link Status Busy Ended message, it When the peer M2PA receives the Link Status Busy Ended message, it
shall stop timer T6. shall stop timer T6.
skipping to change at page 34, line 24 skipping to change at page 34, line 32
The Backward Sequence Number is set to the FSN of the last User Data The Backward Sequence Number is set to the FSN of the last User Data
message M2PA received from its peer. This serves as an M2PA-level message M2PA received from its peer. This serves as an M2PA-level
acknowledgement of the message. After the link is placed in service acknowledgement of the message. After the link is placed in service
and before a User Data message has been received, the BSN is set to 0. and before a User Data message has been received, the BSN is set to 0.
When M2PA receives a message with Backward Sequence Number equal to When M2PA receives a message with Backward Sequence Number equal to
'n', it may remove all messages with Forward Sequence Number <= n from 'n', it may remove all messages with Forward Sequence Number <= n from
its queue. its queue.
If M2PA receives a User Data message with an FSN that is out of order, If M2PA receives a User Data message with an FSN that is out of order,
the message should be discarded. M2PA shall fail the link.
M2PA may send acknowledgement of a received message in an outgoing M2PA may send acknowledgement of a received message in an outgoing
User Data or Link Status message. User Data or Link Status message.
If there is no other User Data or Link Status message to be sent when
there is a message to acknowledge, M2PA may send a Link Status In
Service message.
Note that since SCTP provides reliable delivery and ordered delivery Note that since SCTP provides reliable delivery and ordered delivery
within the stream, M2PA does not need to perform retransmissions. within the stream, M2PA does not need to perform retransmissions.
4.2.2 Link activation and restoration 4.2.2 Link activation and restoration
When MTP3 requests that M2PA activate or restore a link by a Start When MTP3 requests that M2PA activate or restore a link by a Start
Request, M2PA shall follow the alignment procedure in section 4.1.3. Request, M2PA shall follow the alignment procedure in section 4.1.3.
4.2.3 Link deactivation 4.2.3 Link deactivation
skipping to change at page 35, line 48 skipping to change at page 36, line 9
signaling link which have not been received by the far end signaling link which have not been received by the far end
M2PA, as well as untransmitted messages, and M2PA, as well as untransmitted messages, and
(2) transferring those messages to the transmission buffers of the (2) transferring those messages to the transmission buffers of the
alternate links. alternate links.
Note that only User Data messages are retrieved and transmitted over Note that only User Data messages are retrieved and transmitted over
the alternate links. Link Status messages shall not be retrieved and the alternate links. Link Status messages shall not be retrieved and
transmitted over the alternate links. transmitted over the alternate links.
M2PA's Sequence Numbers are 16 bits long. MTP2's Forward and Backward M2PA's Sequence Numbers are 24 bits long. MTP2's Forward and Backward
Sequence Numbers are only seven bits long. Hence it is necessary for Sequence Numbers are only seven bits long. Hence it is necessary for
MTP3 to accommodate the larger sequence numbers. This is done through MTP3 to accommodate the larger sequence numbers. This is done through
the use of the Extended Changeover Order (XCO) and Extended Changeover the use of the Extended Changeover Order (XCO) and Extended Changeover
Acknowledgement (XCA) messages instead of the Changeover Order (COO) Acknowledgement (XCA) messages instead of the Changeover Order (COO)
and Changeover Acknowledgement (COA) messages. The XCO and XCA and Changeover Acknowledgement (COA) messages. The XCO and XCA
messages are specified in Reference [7] section 9.8.1 and Reference messages are specified in Reference [7] section 9.8.1 and Reference
[3] T1.111.4, section 15.4. Only the XCO and XCA messages from [7] or [3] T1.111.4, section 15.4. Only the XCO and XCA messages from [7] or
[3] are required. The BSN is placed in the XCO/XCA message as [3] are required. The BSN is placed in the XCO/XCA message as
explained in [7] and [3]. explained in [7] and [3].
Also, the following MTP3/MTP2 primitives must use the larger sequence Also, the following MTP3/MTP2 primitives must use the larger sequence
numbers: numbers:
- BSNT Confirmation - BSNT Confirmation
- Retrieval Request and FSNC - Retrieval Request and FSNC
skipping to change at page 46, line 15 skipping to change at page 46, line 15
7. IANA Considerations 7. IANA Considerations
7.1 SCTP Payload Protocol Identifier 7.1 SCTP Payload Protocol Identifier
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA
is TBD. is TBD.
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is SCTP Payload Data chunk is
M2PA TBD M2PA 5
The SCTP Payload Protocol Identifier is included in each SCTP Data The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but may be used by Protocol Identifier is not directly used by SCTP but may be used by
certain network entities to identify the type of information being certain network entities to identify the type of information being
carried in a Data chunk. carried in a Data chunk.
The User Adaptation peer may use the Payload Protocol Identifier as a The User Adaptation peer may use the Payload Protocol Identifier as a
way of determining additional information about the data being way of determining additional information about the data being
presented to it by SCTP. presented to it by SCTP.
skipping to change at page 47, line 34 skipping to change at page 47, line 34
(c) Detailed definition of each component of the parameter value. (c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type, (d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within multiple instances of this parameter type may be found within
the same message type. the same message type.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the following for their valuable The authors would like to thank the following for their valuable
comments and suggestions: Brian Tatum, Jeff Copley, Monique Bernard, comments and suggestions: Brian Tatum, Jeff Copley, Monique Bernard,
Wayne Davis, Cliff Thomas, Brian Bidulock, Ian Rytina, Al Varney. Wayne Davis, Cliff Thomas, Ian Rytina, Al Varney.
9. References 9. 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 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7
(SS7) - Message Transfer Part (MTP)'. (SS7) - Message Transfer Part (MTP)'.
[3] ANSI T1.111-2000, American National Standard for [3] ANSI T1.111-2000, American National Standard for
skipping to change at page 49, line 43 skipping to change at page 49, line 43
gregside consulting EMail: gregside@rogers.com gregside consulting EMail: gregside@rogers.com
Kanata, Ontario Kanata, Ontario
Canada Canada
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
This Internet Draft expires August 2002. Brian Bidulock Tel +1-972-839-4489
OpenSS7 Project EMail: bidulock@openss7.org
4701 Preston Park Blvd. #424
Plano, TX 75093
USA
This Internet Draft expires November 2002.
 End of changes. 

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