| draft-ranjith-sigtran-gr303ua-00 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-ranjith-sigtran-gr303ua-00.txt.
Internet Engineering Task Force Ranjith Mukundan
Wipro Technologies
Ken Morneault
Cisco Systems
Expires in six months October 2002
GR-303 extensions to the IUA protocol
<draft-ranjith-sigtran-gr303ua-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http//www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http//www.ietf.org/shadow.html.
Abstract
This document defines a mechanism for backhauling of GR-303 [2]
messages over IP by extending the ISDN User Adaptation Layer
Protocol [3] and to be the base for a GR-303 User Adaptation (GR-
303UA) implementation.
Table of Contents
1.0 Introduction ..................................................2
1.1 Scope ......................................................2
1.2 Terminology ................................................3
1.3 GR-303 Overview ............................................3
1.4 Proposed GR-303 Backhaul Architecture ......................5
2.0 Changes from IUA ..............................................6
2.1 New Message Classes for GR-303UA ..........................6
2.2 Message Header ............................................6
3.0 IANA Considerations ...........................................8
4.0 Security Considerations .......................................8
5.0 References ...................................................9
Ranjith Mukundan/Ken Morneault [Page 1]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
5.1 Normative References .......................................9
5.2 Informative References .....................................9
6.0 Acknowledgements .............................................10
7.0 Author's Addresses ...........................................10
1.0 Introduction
This document describes a method of implementing GR-303 [2] backhaul
messaging over IP using a modified version of the ISDN User
Adaptation Protocol (IUAP) [3]. The GR-303UA builds on top of IUA
defining the necessary extensions to IUA for GR-303 implementation.
1.1 Scope
There is a need for Switched Circuit Network (SCN) GR-303 signaling
protocol delivery, to cater to two scenarios:
Scenario 1: Delivery from a GR-303 Signaling Gateway (SG) to
a Media Gateway Controller (MGC). In this scenario, the
traditional "TDM-based" Remote Digital Terminal (RDT) will
interconnect to a SG.
Scenario 2: Delivery from an "IP-based" distributed Remote
Digital Terminal (RDT) to a Voice Gateway (VG). In this
scenario, the VG will connect to a traditional "TDM-based"
Local Digital Switch (LDS).
The delivery mechanism should support the following GR-303 protocol
entities:
- Time-slot Management Channel (TMC) Protocol [2]
- Common Signaling Channel (CSC) Protocol [2]
- Embedded Operations Channel (EOC) Protocol [2 & 4]
Unless specifically mentioned, the details in this document are
applicable to all the three aforementioned GR-303 protocol entities.
It is to be noted that, owing to the 'hybrid' nature of the GR-303
signaling system, in the GR-303 TMC option, call processing and
terminal supervision signaling also comprises of specific in-band
Robbed Bit Signaling (RBS) signals (ABCD bit patterns) for different
types of subscriber-loops (e.g., Ground Start, Loop Start, Loop
Reverse Battery etc). To transport the in-band signals over the IP
network, other protocols like MEGACO [6]/Media Gateway Control
Protocol (MGCP) [7] (with concomitant new or existing MEGACO/MGCP
packages) OR RTP [8 & 9] will have to be used in conjunction with
GR-303UA. Typically, MEGACO/MGCP would be used in scenario 1 and RTP
in Scenario 2.
Ranjith Mukundan/Ken Morneault [Page 2]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
1.2 Terminology
Remote Digital Terminal (RDT) - An access system located in the
outside plant. RDT's main function is to multiplex traffic from a
number of subscriber lines onto a high-speed transmission facility
(SONET, DS3, or DS1s) for transport to/from the central office. The
maximum number of access lines per RDT is 2048 per interface group.
These access lines can be made to share between 1 and 28 DS1s with
the flexible concentration supported by GR-303. When the number of
DS1 facilities are 2 or more, GR-303 signaling interface
specification mandates a stand-by "protection" signaling channel to
be supported on a DS1 facility different from the DS1 facility that
hosts the primary signaling channels.
Integrated Digital Terminal (IDT) - The switch resources used to
manage and support a single interface group of the RDT. The IDT
interface coordinates operations, administration, and management of
the RDT, including facility terminations, control data links, and
other functions.
Local Digital Switch (LDS) - The switching system (Class-5) located
in the central office that provides switched services such as POTS,
ISDN, or Centrex to subscriber lines on RDTs. An IDT is a logical
entity within the LDS.
1.3 GR-303 Overview
GR-303 is a Bellcore specification [2] that defines a set of generic
interface requirements that allow Class-5 digital switches from one
vendor to interface with access systems from another. Access
systems include digital loop carriers (DLCs) or hybrid fiber/coax
residential broadband systems that are typically used to provide
service to remote concentration groups, as well as extending the
service areas.
The Figure 1 below shows the major building blocks of an Integrated
Digital Loop Carrier (IDLC) using GR-303 interface. An IDLC system
consists of an integrated digital terminal (IDT) located in the
switch and a remote digital terminal (RDT) located in the outside
plant or in some cases at the customer premise. GR-303 provides for
flexible concentration of bandwidth into the LDS for analog
services, and 4:1 Integrated Service Digital Network (ISDN) Basic
Rate Access (BRA). In addition, it provides extensive Operations,
Administration, Management & Provisioning (OAM&P) capabilities for
managing RDTs.
Ranjith Mukundan/Ken Morneault [Page 3]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
+-----------+ GR-303 interface
| LDS | Group (1 - 28 DS1s)
| | +--------+ o--o
| | DS1 | |------- /\
| +------|---------------------| | --
| | IDT | DS1 | RDT |
| +------|---------------------| | o--o
| | | |------- /\
+-----------+ +--------+ --
|<---------- IDLC system ------------->|
Figure 1 GR-303 IDLC System
The maximum number of DS0s supported is 672. Four of these DS0s
are reserved for signaling (EOC and TMC/CSC on primary DS1, EOC and
TMC/CSC on protection DS1).
The GR-303 interface is composed of 1 to 28 DS-1 facilities
connecting the IDT at the central office and the RDT. Standby
signaling channel protection is not available when there is only D1
in the GR-303 interface. For GR-303 interface spanning 2 or more
(upto 28) DS1s, two of these DS-1 facilities carry signaling
channels. The first carries the primary signaling channels, while a
separate DS-1 facility is used to carry the redundant signaling
channels for protection.
GR-303 defines three types of message-based signaling channels
1. Embedded Operations Channel (EOC) - Uses a DS0 (64kbps, clear
channel) on the primary DS1 facility (time slot # 12). And another
DS0 is used for EOC protection on a separate DS1 facility. The EOC
channel is primarily used for carrying Path Protection Switching (PPS)
and OAM&P-related messaging. The higher layer protocols used with
this channel include LAPD subset for layer 2, Convergence sub-layer &
Common Management Information Service Element (CMISE)/Remote
Operations Services Element (ROSE)/ASN.1 sub-layer for layer 3.
2. Timeslot Management Channel (TMC) - Uses a DS0 (64kbps, clear
channel) on the primary DS1 facility (time slot # 24). And another
DS0 is used for TMC protection on a separate DS1 facility. The TMC
channel is primarily used to perform per-call time-slot allocation
and call processing messages between the RDT and the LDS. The
higher layer protocols used with this channel are LAPD subset for
layer 2, and a subset of Q.931 for layer 3.
Ranjith Mukundan/Ken Morneault [Page 4]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
As mentioned earlier in this document, when TMC is used, the bearer
channels will still need to use RBS for transmitting call-processing
and subscriber line supervision in-band messages between the RDT and
the LDS. In other words, signaling between the RDT and IDT is a
hybrid of time slot management channel and robbed-bit (TMC/RBS)
signaling.
3. Common Signaling Channel (CSC) - This signaling channel is an
option that is used instead of TMC for clean out-of-band signaling
implementation. In this case, bearer channels are not required to
carry RBS since CSC messages handle both call supervision and time
slot assignment. The higher layer protocols used with this channel
are LAPD subset for layer 2, and a subset of Q.931 for layer 3.
1.4 Proposed GR-303 Backhaul Architecture
Figure 2 below, depicts the backhaul architecture for the two
scenarios described earlier.
Scenario 1
****** GR-303 ****** IP *******
*RDT *---------------* SG *--------------* MGC *
****** ****** *******
Scenario 2
****** GR-303 ****** IP ********
*LDS *---------------* VG *--------------*IP-RDT*
* * *(SG)* * *
****** ****** ********
+-----+ +-------+
|GR303| (NIF) | GR303 |
| L3 | | L3 |
+-----+ +-----+-------+ +-------+
| | | |GR303UA| |GR303UA|
|GR303| |GR303+-------+ +-------+
| L2 | | L2 | SCTP | | SCTP |
| | | +-------+ +-------+
| | | | IP | | IP |
+-----+ +-----+-------+ +-------+
Figure 2 GR-303 Backhaul Architecture
Ranjith Mukundan/Ken Morneault [Page 5]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
NIF - Nodal Interworking function
SCTP - Stream Control Transmission Protocol
GR303UA - GR-303 User Adaptation Layer Protocol
GR303 L2 - A subset of LAPD
GR303 L3 - TMC/CSC (a Q.931 subset) OR
EOC Convergence & CMISE/ROSE/ASN.1 sub-layers
2.0 Changes from IUA
This section outlines the differences between GR-303UA and IUA.
2.1 New Message Classes for GR-303UA
The GR-303 TMC/CSC and EOC Layer 2 to Layer 3 primitives need to be
handled in a different way from the IUA boundary primitive transport
messages and the boundary primitive transport messages of other
IUA extensions (i.e. V5 or DPNSS). Therefore, it is neccessary to
distinguish between these from other IUA-based boundary primitive
transport message types [3] by means of the Message Class parameter.
In order to support GR-303 layer 2 <=> layer 3 interface boundary
primitives, the following Message Classes are introduced (to be
assigned by IANA):
12 GR-303 EOC Boundary Primitives Transport Messages (GEPTM)
13 GR-303 TMC/CSC Boundary Primitives Transport Messages (GXPTM)
Similar to IUA, other valid message classes for GR-303UA are the
following:
0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
2.2 Message Header
IUA Message header [3] has the format as shown in Figure 3 below.
GR-303UA, being extension of IUA, will have the same format.
Ranjith Mukundan/Ken Morneault [Page 6]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 IUA Message Header
Where, the Tag value for the Integer-based Interface Identifier is
0x1. The length is always set to a value of 8.
And the DLCI format is shown below in Figure 4.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | SPR | SAPI |
+-----------------------------------------------+
| 1 | TEI |
+-----------------------------------------------+
Figure 4 DLCI Format
SPR : Spare 2nd bit in octet 1, (1 bit)
SAPI: Service Access Point Identifier, 3rd through 8th bits in octet
1 (6 bits)
TEI : Terminal Endpoint Identifier, 2nd through 8th bits in octet 2
(7 bits)
The DLCI field (including the SAPI and TEI) is coded in accordance
with Q.921.
The following SAPI/TEI combinations shall be supported for GR-303
TMC/CSC and EOC
TMC Data-link function
----------------------
SAPI TEI
------------------------------------------
Call Processing 0 0
TMC Path Switch Ops 1 0
Ranjith Mukundan/Ken Morneault [Page 7]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
EOC Data-link function
----------------------
SAPI TEI
----------------------------------------------------
TMC Path Switch Ops 1 0
RDT - Provisioning/Mem Admin 1 1
RDT - Maint/Surveillance OS 1 2
RDT - Testing OS 1 3
RDT - IDT 1 4
RDT - Test System Controller 1 1 5
RDT - Test System Controller 2 1 6
RDT - Test System Controller 3 1 7
user assignable 1 8
user assignable 1 9
user assignable 1 10
user assignable 1 11
3.0 IANA Considerations
A request will be made to IANA to assign a GR-303UA value for the
SCTP Payload Protocol Identifier field used in SCTP Payload Data
chunks.
The following value for the SCTP Payload Protocol Identifier field
should be used for GR-303UA:
SCTP Payload Protocol ID xxx - tba by IANA
The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, 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 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 of determining whether the message is for IUA, V5UA, DUA or
GR-303UA.
4.0 Security Considerations
The security considerations discussed for the IUA [3] Section 6.0
apply to this document as well.
Ranjith Mukundan/Ken Morneault [Page 8]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
5.0 References
5.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
[2] GR-303-CORE Issue 4, "IDLC Generic Requirements, Objectives, and
Interface", December 2000 and the associated Issues List Report GR-
303-ILR Issue 4A, December 2000.
[3] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057,
February 2001.
[4] GR-303-IMD, "IDLC System Generic Operations Interface" (formerly
TR-TSY-000303 Supplement 3), Issue 1, December 1998
[5] IUA (RFC3057) Implementors Guide, draft-ietf-sigtran-iua-imp-
guide-01.txt, Oct 2002
5.2 Informative References
[6] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J.
Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
[7] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S.,
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October
1999.
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP
A Transport Protocol for Real-Time Applications", RFC 1889, January
1996.
[9] Schulzrinne, H. and Petrack, S., "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[10] TR-NWT-000057, "Functional Criteria for Digital Loop Carrier
Systems", Issue 2, January 1993.
[11] ANSI T1.403, "Network and Customer Installation Interfaces - DS1
Electrical Interface", May 1999.
[12] ANSI T1.403.02, "Network and Customer Installation Interfaces -
DS1 Robbed-Bit Signaling State Definition", May 1999.
Ranjith Mukundan/Ken Morneault [Page 9]
Internet Draft draft-ranjith-sigtran-gr303ua-00.txt October 2002
6.0 Acknowledgments
None
7.0 Author's Addresses
Ranjith Mukundan Phone +91-80-8520408
Wipro Technologies Email ranjith.mukundan@wipro.com
72, Electronics City,
Hosur Main Road,
Bangalore 561229
India
Ken Morneault Phone +1-703-484-3323
Cisco Systems Inc. EMail kmorneau@cisco.com
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Ranjith Mukundan/Ken Morneault [Page 10]
|
Documentation