draft-ietf-sigtran-v5ua-00.txt   draft-ietf-sigtran-v5ua-01.txt 
Internet Engineering Task Force Eva Weilandt Internet Engineering Task Force Eva Weilandt
INTERNET DRAFT Neeraj Khanchandani INTERNET DRAFT Neeraj Khanchandani
Fahir Ergincan Fahir Ergincan
Sanjay Rao Sanjay Rao
Nortel Networks Nortel Networks
Expires in six months February 2001 Expires in six months July 2001
V5.2-User Adaption Layer (V5UA) V5.2-User Adaption Layer (V5UA)
<draft-ietf-sigtran-v5ua-00.txt> <draft-ietf-sigtran-v5ua-01.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 RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts. groups may also distribute working documents as Internet- Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Abstract Abstract
This document defines a mechanism for backhauling of V5.2 messages This document defines a mechanism for backhauling of V5.2 messages
over IP using the Stream control Transmission Protocol (SCTP). This over IP using the Stream control Transmission Protocol (SCTP). This
protocol would be used between a Signaling Gateway (SG) and a Media protocol would be used between a Signaling Gateway (SG) and a Media
Gateway controller (MGC). It is assumed that the SG receives V5.2 sig- Gateway controller (MGC). It is assumed that the SG receives V5.2 sig-
naling over a standard V5.2 interface. naling over a standard V5.2 interface.
This document aims to build on top of the ISDN User Adaptation Layer This document aims to build on top of the ISDN User Adaptation Layer
Protocol (<draft-ietf-sigtran-iua-10.txt>). It defines all differences Protocol (RFC 3057). It defines all differences to the IUAP needed for
to the IUAP needed for the V5.2 implementation. the V5.2 implementation.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
1.1. Scope .................................................... 3 1.1. Scope .................................................... 3
1.2. Terminology .............................................. 3 1.2. Terminology .............................................. 3
1.3. V5.2 Overview ............................................ 5 1.3. V5.2 Overview ............................................ 5
1.4. Addition to boundary primitives .......................... 7 1.4. TEI Management for BRI over V5UA ......................... 7
1.4.1. V5 specific boundary primitives ...................... 7 1.5. Client/Server Model ...................................... 7
2. SCTP Stream Management ....................................... 8 1.6. Addition to boundary primitives .......................... 7
3. Proposed V5.2 Backhaul Architecture .......................... 8 1.6.1. V5 specific boundary primitives ...................... 7
3.1. V5UA Message Header ...................................... 9 2. SCTP Stream Management ....................................... 9
3.2. V5 Naming Conventions for Interface Identifier ........... 10 3. Proposed V5.2 Backhaul Architecture .......................... 9
3.3. V5 Additions to IUA Boundary Primitives .................. 11 3.1. V5UA Message Header ...................................... 10
3.4. Link Status Messages ..................................... 12 3.2. V5 Naming Conventions for Interface Identifier ........... 11
3.5. Sa-Bit Messages .......................................... 13 3.3. V5 Additions to IUA Boundary Primitives .................. 12
4. Examples ..................................................... 14 3.4. Link Status Messages ..................................... 13
4.1. Link Identification Procedure (successful) ............... 14 3.5. Sa-Bit Messages .......................................... 14
5. IANA Considerations .......................................... 15 4. Procedures ................................................... 15
5.1. SCTP Payload Protocol Identifier ......................... 16 4.1. V5 Layer 1 failure ....................................... 15
6. Acknowledgements ............................................. 16 4.2. Loss of V5UA peer ........................................ 16
7. References ................................................... 16 5. Examples ..................................................... 17
8. Author's Addresses ........................................... 17 5.1. Link Identification Procedure (successful) ............... 17
6. IANA Considerations .......................................... 18
6.1. SCTP Payload Protocol Identifier ......................... 18
7. Acknowledgements ............................................. 18
8. References ................................................... 19
9. Author's Addresses ........................................... 19
1. Introduction 1. Introduction
This document describes a method of implementing V5.2 backhaul messag- This document describes a method of implementing V5.2 backhaul messag-
ing over IP using a modified version of the ISDN User Adapation Layer ing over IP using a modified version of the ISDN User Adapation Layer
Protocol (IUAP) [1]. The V5UA builds on top of IUA defining the ne- Protocol (IUAP) [1]. The V5UA builds on top of IUA defining the neces-
cessary extensions to IUA for a V5.2 implementation. sary extensions to IUA for a V5.2 implementation.
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 a V5.2 Signaling Gateway (SG) to a Media Gateway con- delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway con-
troller (MGC) analog to the implementation of the ISDN Q.921 User troller (MGC) analog to the implementation of the ISDN Q.921 User
Adaption Layer (IUA) as described in [1]. Adaption Layer (IUA) as described in [1].
This draft supports analog telephone access, ISDN basic rate access This draft supports analog telephone access, ISDN basic rate access
and ISDN Primary rate access over a V5.2 interface. and ISDN Primary rate access over a V5.2 interface.
skipping to change at page 5, line 20 skipping to change at page 5, line 20
1.3. V5.2 Overview 1.3. V5.2 Overview
V5.2 is an industry standard ETSI interface (reference ETS 300 347-1) V5.2 is an industry standard ETSI interface (reference ETS 300 347-1)
defined between a Local Exchange (LE) and an Access Network (AN) pro- defined between a Local Exchange (LE) and an Access Network (AN) pro-
viding access to the following types: viding access to the following types:
- Analog telephone access - Analog telephone access
- ISDN Basic rate access - ISDN Basic rate access
- ISDN Primary Rate access (V5.2) - ISDN Primary Rate access
- Other analog or digital accesses for semi-permanent connections - Other analog or digital accesses for semi-permanent connections
without associated outband signaling information without associated outband signaling information
The original V5 specification (V5.1) uses 2048 kbps links in a The original V5 specification (V5.1) uses 2048 kbps links in a
non-concentrating fashion. V5.2 may use up to 16 such interface non-concentrating fashion. V5.2 may use up to 16 such interface
links and supports concentration. links and supports concentration.
---------- ---------- o--o ---------- ---------- o--o
| | E1 | |------- / | | E1 | |------- /
skipping to change at page 6, line 42 skipping to change at page 6, line 42
- LAPV5-EF - LAPV5-EF
- LAPV5-DL - LAPV5-DL
Layer 3: Layer 3:
- V5-Link Control - V5-Link Control
- V5-BCC - V5-BCC
- V5-PSTN - V5-PSTN
- V5-Control - V5-Control
- V5-Protection - V5-Protection
In the backhaul architecture, the protocols are distributed over SG
and MGC as shown below.
MGC SG MGC SG
+------------+ +-------+-------+ +------------+ +-------+-------+
| Lnk Cntrl | | | | | Lnk Cntrl | | | |
+------------+ | | | +------------+ | | |
| Cntrl | | | | | Cntrl | | | |
+------------+ V5UA | | | V5 +------+ +------------+ V5UA | | | V5 +------+
| BCC | <--------> | LAPV5 | LAPV5 | <----> | AN | | BCC | <--------> | LAPV5 | LAPV5 | <----> | AN |
+------------+ | -DL | -EF | +------+ +------------+ | -DL | -EF | +------+
| PSTN | | | | | PSTN | | | |
+------------+ | | | +------------+ | | |
| Protection | | | | | Protection | | | |
+------------+ +-------+-------+ +------------+ +-------+-------+
1.4. Addition to boundary primitives 1.4. TEI Management for BRI over V5UA
1.4.1. V5 specific boundary primitives Dynamic TEI Management for BRI over V5 shall be located on the MGC.
1.5. Client/Server Model
The Client/Server Model for V5UA should follow the model as defined
for IUAP.
The SCTP (and UDP/TCP) registered User Port Number Assignment for V5UA
is ? (tbd).
1.6. Addition to boundary primitives
1.6.1. V5 specific boundary primitives
Extending IUAP to support V5.2 requires the introduction of new boun- Extending IUAP to support V5.2 requires the introduction of new boun-
dary primitives for the Q.921/Q.931 boundary in accordance with the dary primitives for the Q.921/Q.931 boundary in accordance with the
definitions in V5.2. definitions in V5.2.
V5.2 reuses just one primitive from the Q.921/Q.931 boundary: the DL- V5.2 reuses the primitives from the Q.921/Q.931 boundary: the DL-DATA
DATA primitive. The responsibility to establish and release data links primitive and the DL-UNIT DATA primitive. The DL-UNIT DATA primitive
is shifted to V5 system management. Therefore the DL-Establish and is only used for ISDN messages and is used and defined as described
DL-Release primitives are replaced by new primitives between system for IUAP.
management and the data link layer [2]:
The responsibility to establish and release data links is shifted to
V5 system management. Therefore the DL-Establish and DL-Release primi-
tives are replaced by new primitives between system management and the
data link layer [2]:
MDL-ESTABLISH MDL-ESTABLISH
The MDL-Establish primitives are used to request, indicate and confirm The MDL-Establish primitives are used to request, indicate and confirm
the outcome of the procedures for establishing multiple frame opera- the outcome of the procedures for establishing multiple frame opera-
tion. tion.
MDL-RELEASE MDL-RELEASE
The MDL-Release primitive is used to indicate the outcome of the pro- The MDL-Release primitive is used to indicate the outcome of the pro-
cedures for terminating multiple frame operation. cedures for terminating multiple frame operation.
In contrary to ISDN, the V5 standards demand that V5.2 system manage- In contrary to ISDN, the V5 standards demand that V5.2 system manage-
ment interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (includ- ment interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (includ-
skipping to change at page 7, line 43 skipping to change at page 8, line 26
separated in a V5 backhaul scenario, V5UA needs to support some ser- separated in a V5 backhaul scenario, V5UA needs to support some ser-
vice for the communication between these two entities. Specifically vice for the communication between these two entities. Specifically
these services include an indication of the status of a link, and mes- these services include an indication of the status of a link, and mes-
sages to support link identification procedure. sages to support link identification procedure.
The new messages are defined as shown below: The new messages are defined as shown below:
MPH-LINK STATUS START REPORTING MPH-LINK STATUS START REPORTING
The MPH-LINK STATUS START REPORTING message is used by V5 system The MPH-LINK STATUS START REPORTING message is used by V5 system
management to request to start reporting the status of a V5 link from management to request to take the link in service for use on a V5
L1 FSM on the SG. interface. On reception of this message L1 FSM on the SG shall also
start reporting the status of the V5 link to the GWC.
MPH-LINK STATUS STOP REPORTING MPH-LINK STATUS STOP REPORTING
The MPH-LINK STATUS STOP REPORTING message is used by V5 system The MPH-LINK STATUS STOP REPORTING message is used by V5 system
management to request to stop reporting the status of a V5 link from management to request to take the link out of service for use on a V5
L1 FSM on the SG. interface. On reception of this message L1 FSM on the SG shall also
stop reporting the status of the V5 link to the GWC.
MPH-LINK STATUS INDICATION MPH-LINK STATUS INDICATION
The MPH-LINK STATUS INDICATION message is used by L1 FSM on the Sig- The MPH-LINK STATUS INDICATION message is used by L1 FSM on the Sig-
nalling Gateway to report the status (operational/non-operational) of nalling Gateway to report the status (operational/non-operational) of
a V5 link to V5 system management. a V5 link to V5 system management.
MPH-SA-BIT SET MPH-SA-BIT SET
The MPH-SA-BIT SET message is used by system management to request The MPH-SA-BIT SET message is used by system management to request
skipping to change at page 8, line 33 skipping to change at page 9, line 17
The MPH-SA-BIT STATUS messages are used between system management in The MPH-SA-BIT STATUS messages are used between system management in
the MGC and L1 FSM in the SG to request reporting of the status of a the MGC and L1 FSM in the SG to request reporting of the status of a
specified Sa bit on the requested link, or to report the status of specified Sa bit on the requested link, or to report the status of
this bit back to system management. For V5 these messages will be this bit back to system management. For V5 these messages will be
used for the Link identification procedure to request or report the used for the Link identification procedure to request or report the
status of the Sa7 bit. This would be equivalent to the MPH-IDR, MPH- status of the Sa7 bit. This would be equivalent to the MPH-IDR, MPH-
IDI or MPH-Elg primitive in V5.2. IDI or MPH-Elg primitive in V5.2.
2. SCTP Stream Management 2. SCTP Stream Management
It is recommended that a separate SCTP stream be used for every It is recommended that one SCTP stream be used for BCC, Link Control,
Envelope Function Address used on a specific C-channel. When an EFA is Common Control and PSTN protocol on a specific c-channel. It is
used on more than one C-channel, one stream per c-channel and EFA is recommended to use a separate SCTP stream for Protection protocol on a
recommended. specific c-channel. It is also recommended to use one SCTP stream for
all ISDN user ports on a specific c-channel. One single stream should
This means that one stream is used for BCC, Link Control, Common Con- not be used to carry data of more than one c-channel.
trol, Protection and PSTN protocol on all c-channels the protocol is
used. One stream is used for the signalling for every ISDN user port
on all c-channels the data for this port is sent.
In addition, it is recommended that one separate SCTP stream be used In addition, it is recommended that one separate SCTP stream be used
for all MPH (link related) messages. for all MPH (link related) messages.
3. Proposed V5.2 Backhaul Architecture 3. Proposed V5.2 Backhaul Architecture
****** V5.2 ****** IP ******* ****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC * * AN *---------------* SG *--------------* MGC *
****** ****** ******* ****** ****** *******
+-----+ +-----+ +-----+ +-----+
|V5.2 | (NIF) |V5.2 | |V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+ +-----+ +----------+ +-----+
| | | |V5UA| |V5UA | | | | |V5UA| |V5UA |
| | | +----+ +-----+ | | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP | |LAPV5| |LAPV5|SCTP| |SCTP |
skipping to change at page 10, line 34 skipping to change at page 11, line 15
Definition Value Definition Value
---------- ------ ---------- ------
ISDN_PROTOCOL 0 - 8175 ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176 PSTN_PROTOCOL 8176
CC_PROTOCOL 8177 CC_PROTOCOL 8177
BCC_PROTOCOL 8178 BCC_PROTOCOL 8178
PROT_PROTOCOL 8179 PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180 LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191 RESERVED 8181 - 8191
For MPH messages for which DLCI and EFA are not used, SAPI, TEI and
EFA shall be set to ZERO and shall be ignored by the receiver. For all
other messages the DLCI shall be set as defined in the V5.2 standard
[2].
The text formatted Interface Identifier SHALL not be supported due to The text formatted Interface Identifier SHALL not be supported due to
the neccessary naming conventions for the Interface Identifier. the neccessary naming conventions for the Interface Identifier.
3.2. V5 Naming Conventions for Interface Identifier 3.2. V5 Naming Conventions for Interface Identifier
The V5 standard demands that V5 System Management keeps track of the The V5 standard demands that V5 System Management keeps track of the
states of all links on a V5 interface. To perform tasks like protec- states of all links on a V5 interface. To perform tasks like protec-
tion switching and bearer channel allocation on the V5 links, it is tion switching and bearer channel allocation on the V5 links, it is
neccessary that system management has the full picture of the signal- neccessary that system management has the full picture of the signal-
ling and bearer channels located on each link. ling and bearer channels located on each link.
skipping to change at page 12, line 7 skipping to change at page 12, line 41
0 Management (MGMT) Message 0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages 3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages
Q.921/Q.931 boundary primitive messages reused by V5.2 as QPTMV5 Q.921/Q.931 boundary primitive messages reused by V5.2 as QPTMV5
messages are: messages are:
1 Data Request Message (MGC -> SG) 1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC) 2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG) 5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC) 6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC) 7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG) 8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC) 9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC) 10 Release Indication (SG -> MGC)
All these messages are defined similar to the QPTM messages. In addi- All these messages are defined similar to the QPTM messages. In addi-
tion, Layer 1 boundary primitive messages are defined: tion, Layer 1 boundary primitive messages are defined:
skipping to change at page 12, line 42 skipping to change at page 13, line 28
All Link Status Messages contain the V5UA Message Header. The Link All Link Status Messages contain the V5UA Message Header. The Link
Identifier portion of the Interface Identifier identifies the physical Identifier portion of the Interface Identifier identifies the physical
link on the SG addressed by the message. For all link status messages, link on the SG addressed by the message. For all link status messages,
the Chnl ID shall be set to '0' and shall be ignored by the receiver. the Chnl ID shall be set to '0' and shall be ignored by the receiver.
The integer value used for the Link Identifier is of local signifi- The integer value used for the Link Identifier is of local signifi-
cance only, coordinated between the SG and MGC. It has to be unique cance only, coordinated between the SG and MGC. It has to be unique
for the link on the SG. for the link on the SG.
The Link Status Start Report Message is used for example by V5 System The Link Status Start Report Message is used by V5 System Management
Management to request reporting from L1 FSM on the status of a partic- to request from L1 FSM to start reporting the status of a particular
ular link, since V5 System Mangement on the MGC must know the status link, since V5 System Management on the MGC must know the status of
of the links on all active V5 interfaces. V5 system management will the links on all active V5 interfaces. This message is also an indica-
send this Message on Interface activation for all links on the inter- tion for the SG that this link is located on a now active interface.
face. The SG will respond immediately to this request with a Link
Status Indication message, and it will then send a Link Status Indica- V5 system management shall send this Message on interface activation
tion message on all subsequent changes of the link status. for all links on the interface. The SG will respond immediately to
this request with a Link Status Indication message, and it will then
send a Link Status Indication message on all subsequent changes of the
link status. Since the SG has no other way to determine whether a link
is on an active interface or not, this message shall always be sent on
interface startup.
To stop this reporting of the status of a link, e.g. at interface To stop this reporting of the status of a link, e.g. at interface
deactivation, System Management sends a Link Status Stop Report Mes- deactivation, System Management sends a Link Status Stop Reporting
sage to the L1 FSM. The SG will then immediately stop reporting the Message to the L1 FSM. The SG will then immediately stop reporting the
status of the particular link. It must not respond in any way to this status of the particular link and will assume the link to be out of
service. It must not respond in any way to this message.
message. Since there is not other way for the SG to know that an interface is
deactivated, this message shall be sent on interface deactivation for
all links on the interface. On reception of this message, the SG may
take L2 down on this link.
The Link Status Start/Stop Report Messages contain the common message The Link Status Start/Stop Report Messages contain the common message
header followed by the V5UA message header. They do not contain any header followed by the V5UA message header. They do not contain any
addition parameters. addition parameters.
The Link Status Indication Message is used by L1 FSM in the SG in The Link Status Indication Message is used by L1 FSM in the SG in
response to a Link Status Request Message to indicate the status of response to a Link Status Request Message to indicate the status of
the particular link. After a Link Status Start Report Message has been the particular link. After a Link Status Start Report Message has been
received by the L1 FSM, it will automatically send a Link Status Indi- received by the L1 FSM, it will automatically send a Link Status Indi-
cation Message every time the status of the particular link changes. cation Message every time the status of the particular link changes.
It will not stop this reporting until it receives a Link Status Stop It will not stop this reporting until it receives a Link Status Stop
Report Message from System Management. Report Message from System Management.
skipping to change at page 14, line 46 skipping to change at page 15, line 43
Sa7 0x7 Addresses the Sa7 bit Sa7 0x7 Addresses the Sa7 bit
There are no other valid values for V5UA. All other values are There are no other valid values for V5UA. All other values are
reserved for future use. reserved for future use.
For the Sa-Bit Status Request and Set Ack messages, the BIT Value For the Sa-Bit Status Request and Set Ack messages, the BIT Value
should be set to '0' by the sender and should be ignored by the should be set to '0' by the sender and should be ignored by the
receiver. receiver.
4. Examples 4. Procedures
4.1. Link Identification Procedure (successful) 4.1. V5 Layer 1 failure
The normal way to handle a Layer 1 failure is described in the V5
standards[2,3] as follows:
- L1FSM detects the Layer 1 failure. It reports this to V5 System
management by sending a MPH-DI primitive for the affected link.
- V5 System management notifies Layer 2 of the Layer 1 outage by
sending a MPH-Layer_1 Failure Ind primitive.
Since Layer1/2 and V5 System Management are no longer co-located in
the backhaul architecture, it does not make sense to notify Layer 2
about Layer 1 failure via V5 system management. Instead Layer 2 shall
be notified directly by Layer 1 on the SG. Layer 1 shall still report
the outage to V5 system management by sending an MPH-DI primitive, but
V5 system management shall not send a MPH-Layer_1 Failure Ind primi-
tive to Layer 2.
4.2. Loss of V5UA peer
If SCTP failure is detected or the heartbeat is lost, the following
procedure shall be performed:
When loss of V5UA peer is detected, the SG will start a timer T1(r)
(tbd). If the connection is reestablished before T1(r) expires, com-
munication should proceed as usual.
After expiry of timer T1(r) and if the connection can not be reesta-
blished, the SG shall behave as if it had received a Link Status Stop
Reporting message for all links connected to this SG.
In case of loss of the V5UA peer, the ASP will start a timer T2(r)
(tbd). This timer shall expire earlier than T1(r) in the SG. The ASP
will continuously try to reestablish the connection. In case it is
successful before T2(r) expires, communication should proceed as
usual.
After expiry of timer T2(r) and if the connection can not be reesta-
blished, the ASP shall behave as if it had received a Link Status
Indication (non-operational) for all links on this SG. The ASP shall
proceed in attempting to reestablish the connection.
When the connection is reestablished after timer T2(r) has expired,
the ASP shall send a Link Status Start Reporting message to the SG for
all links on active V5 interfaces on the SG.
An example for the message flow in case of reestablishment of the con-
nection is shown below for one active link on the SG:
ASP SG
| |
| -------- Link Status Start Reporting ---------> |
| |
| <--------- Link Status Ind (op) --------------- |
| |
5. Examples
5.1. Link Identification Procedure (successful)
An example for the message flow for an LE initiated Link Identifica- An example for the message flow for an LE initiated Link Identifica-
tion procedure is shown below. An active association between ASP and tion procedure is shown below. An active association between ASP and
SG is established prior to the following messages flows, and the V5 SG is established prior to the following messages flows, and the V5
interface is already activated: interface is already activated:
ASP SG ASP SG
| | | |
| ------ Data Request (LnkCtrl: FE-IDReq) ------> | | ------ Data Request (LnkCtrl: FE-IDReq) ------> |
| <-------------- Data Indication --------------- | | <-------------- Data Indication --------------- |
| | | |
| <------- Data Request (LnkCtrl: FE-IDAck) ----- | | <------- Data Request (LnkCtrl: FE-IDAck) ----- |
skipping to change at page 15, line 47 skipping to change at page 18, line 24
| ------- Data Request (LnkCtrl: FE-IDAck) -----> | | ------- Data Request (LnkCtrl: FE-IDAck) -----> |
| <----------------- Data Indication -----------> | | <----------------- Data Indication -----------> |
| | | |
| <------ Data Request (LnkCtrl: FE-IDRel) ------ | | <------ Data Request (LnkCtrl: FE-IDRel) ------ |
| ---------------- Data Indication -------------> | | ---------------- Data Indication -------------> |
| | | |
| ------------ Sa-Bit Set ( Sa7, ONE ) ---------> | | ------------ Sa-Bit Set ( Sa7, ONE ) ---------> |
| <----------- Sa-Bit Set Ack (Sa 7) ------------ | | <----------- Sa-Bit Set Ack (Sa 7) ------------ |
| | | |
5. IANA Considerations 6. IANA Considerations
5.1. SCTP Payload Protocol Identifiers 6.1. SCTP Payload Protocol Identifiers
A request will be made to IANA to assign an V5UA value for the Payload A request will be made to IANA to assign an V5UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Payload Protocol Identifier will be registered: Payload Protocol Identifier will be registered:
V5UA "?" V5UA "?"
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.
6. Acknowledgements 7. Acknowledgements
The authors would like to thank Milos Pujic, Graeme Currie for their The authors would like to thank Milos Pujic, Graeme Currie, Berthold
valuable comments and suggestions. Jaekle for their valuable comments and suggestions.
7. References 8. References
[1] ISDN Q.921-User Adaptation Layer <draft-ietf-sigtran-iua-10.txt> [1] ISDN Q.921-User Adaptation Layer RFC 3057
[2] EN 300 324-1 (1999): V interfaces at the digital Local Exchange [2] EN 300 324-1 (1999): V interfaces at the digital Local Exchange
(LE); V5.1 interface for the support of Access Network (AN); Part (LE); V5.1 interface for the support of Access Network (AN); Part
1: V5.1 interface specification. 1: V5.1 interface specification.
[3] EN 300 347-1 (1999): V interfaces at the digital Local Exchange [3] EN 300 347-1 (1999): V interfaces at the digital Local Exchange
(LE); V5.2 interface for the support of Access Network (AN); Part (LE); V5.2 interface for the support of Access Network (AN); Part
1: V5.2 interface specification. 1: V5.2 interface specification.
[4] ETS 300 125 (1991) : DSS1 protocol; User-Network interface data [4] ETS 300 125 (1991) : DSS1 protocol; User-Network interface data
skipping to change at page 17, line 5 skipping to change at page 19, line 29
Q.921). Q.921).
[5] ETS 300 166 (08/1993) : Transmission and Multiplexing; Physical [5] ETS 300 166 (08/1993) : Transmission and Multiplexing; Physical
and electrical characteristic of hierarchical digital interfaces and electrical characteristic of hierarchical digital interfaces
(Standard is based on G.703). (Standard is based on G.703).
[6] ETS 300 167 (08/1993) : Transmission and Multiplexing; Functional [6] ETS 300 167 (08/1993) : Transmission and Multiplexing; Functional
characteristic of 2048 kbits/s interfaces (Standard is based on characteristic of 2048 kbits/s interfaces (Standard is based on
G.704, G.706). G.704, G.706).
8. Author's Addresses 9. Author's Addresses
Dr. Eva Weilandt Tel +49 7545 96 7267 Dr. Eva Weilandt Tel +49 7545 96 7267
Nortel Networks Germany Email eva.weilandt@nortelnetworks.com Nortel Networks Germany Email eva.weilandt@nortelnetworks.com
88039 Friedrichshafen 88039 Friedrichshafen
Germany Germany
Sanjay Rao Tel +1-919-991-2251 Sanjay Rao Tel +1-919-991-2251
Nortel Networks Email rsanjay@nortelnetworks.com Nortel Networks Email rsanjay@nortelnetworks.com
35 Davis Drive 35 Davis Drive
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Neeraj Khanchandani Tel +1-919-991-2274 Neeraj Khanchandani Tel +1-919-991-2274
Nortel Networks Email neerajk@nortelnetworks.com Nortel Networks Email neerajk@nortelnetworks.com
35 Davis Drive 35 Davis Drive
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Dr. Fahir Ergincan Tel +49 7545 96 8844 Dr. Fahir Ergincan Tel +1-613-763-4929
Nortel Networks Germany Email fahir@nortelnetworks.com Nortel Networks Email fahir@nortelnetworks.com
88039 Friedrichshafen 100 Constellation Crecent
Germany Nepean, ON K2G6J8
Canada
This Draft Expires in 6 months from February,2001 This Draft Expires in 6 months from July,2001
 End of changes. 

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