Multiservice Switching Forum
Implementation Agreement
Document Number: 01.00
Status: PROVISIONAL
Multiservice Switching Forum
Contribution Number: MSF98.001
Working Group: Architecture
Title: Multiservice Switching Forum System Architecture
Source: Cisco, MCI WorldCom, Bellcore
Working Group Chairperson: Mark Klerer
Working Group Vice Chairperson: Roger Ward
Date: November 17, 1998
Abstract:
This document describes the overall purpose and objectives of the Multiservice Switching Forum (MSF). It defines a
layered logical model that separates control from switching and adaptation functions for voice, video, and data
services. The principal focus of the MSF is definition of the interfaces and protocols between the control plane and
the switching/adaptation planes and the management of this interaction. The document also gives several examples
of physical implementations of this logical model.
STATEMENT REGARDING DRAFT IMPLEMENTATION AGREEMENTS
The Multiservice Switching Forum (MSF) is responsible for developing Implementation Agreements which can be
used by developers and network operators to ensure interoperability between components from different vendors.
MSF Implementation Agreements are formally ratified via a Straw Ballot and then a Principal Member Ballot.
Draft MSF Implementation Agreements may be published before formal ratification via Straw or Principal Member
Ballot. In order for this to take place, the MSF Technical Committee must formally agree that a draft Implementation Agreement should be progressed through the balloting process. A Draft MSF Implementation Agreement is
given a document number in the same manner as an Implementation Agreement.
Draft Implementation Agreements may be revised before or during the full balloting process. The revised document
is allocated a new major or minor number and is published. The original Draft Implementation Agreement remains
published until the Technical Committee votes to withdraw it.
After being ratified by a Principal Member Ballot, the Draft Implementation Agreement becomes an Implementation
Agreement. Earlier Draft Implementation Agreements remain published until the Technical Committee votes to
MSF Confidential
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
withdraw them.
DISCLAIMER
The information in this publication is believed to be accurate as of its publication date. Such information is subject
to change without notice and the Multiservice Switching Forum is not responsible for any errors or omissions. The
Multiservice Switching Forum does not assume any responsibility to update or correct any information in this
publication. Notwithstanding anything to the contrary, neither the Multiservice Switching Forum nor the publisher
make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability
of any information contained in this publication. No liability of any kind whether based on theories of tort, contract,
strict liability or otherwise, shall be assumed or incurred by the Multiservice Switching Forum, its member
companies, or the publisher as a result of reliance or use by any party upon any information contained in this
publication. All liability for any implied or express warranty of merchantability or fitness for a particular purpose is
hereby disclaimed.
The receipt or any use of this document or its contents does not in any way create by implication
or otherwise:
Any express or implied license or right to or under any Multiservice Switching Forum
member company’s patent, copyright, trademark or trade secret rights which are or may
be associated with the ideas, techniques, concepts or expressions contained herein; nor
Any warranty or representation that any Multiservice Switching Forum member companies will announce
any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced
product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor
Any commitment by a Multiservice Switching Forum company to purchase or otherwise procure any product(s) and/or service(s) that embody any or all of the ideas, technologies, or concepts contained herein; nor
Any form of relationship between any Multiservice Switching Forum member companies and the recipient
or user of this document.
Implementation or use of specific Multiservice Switching Forum Implementation Agreements or recommendations
and Multiservice Switching Forum specifications will be voluntary, and no company shall agree or be obliged to
implement them by virtue of participation in the Multiservice Switching Forum.
For addition information contact:
Multiservice Switching Forum
39355 California Street, Suite 307, Fremont, CA 94538
(510) 608-3990
(510) 608-3995 (fax)
info@msforum.org
November 3, 1998
MSF Confidential
ii
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
WWW.MSFORUM.ORG
November 3, 1998
MSF Confidential
iii
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
TABLE OF CONTENTS
1
INTRODUCTION ............................................................................................................................................... 1
1.1
FORUM PURPOSE ............................................................................................................................................ 1
1.2
DEFINITIONS ................................................................................................................................................... 1
1.3
ARCHITECTURE OBJECTIVES ..................................................................................................................... 1
1.4
RELEVANT STANDARDS BODIES .................................................................................................................... 2
2
MULTI-PLANE SYSTEM ARCHITECTURE ................................................................................................ 2
2.1
ADAPTATION PLANE ....................................................................................................................................... 4
2.2
SWITCHING PLANE .......................................................................................................................................... 4
2.3
CONTROL PLANE ............................................................................................................................................ 4
2.4
APPLICATIONS PLANE ..................................................................................................................................... 5
2.5
MANAGEMENT PLANE .................................................................................................................................... 5
3
SYSTEM REQUIREMENTS ............................................................................................................................. 6
3.1
SYSTEM MODULARITY.................................................................................................................................... 6
3.2
PROTOCOL REQUIREMENTS ............................................................................................................................ 7
3.3
SEPARATION OF BEARER AND CONTROL....................................................................................................... 10
3.4
INTRA-SYSTEM INTERFACES ......................................................................................................................... 10
3.5
SINGLE NODE VIEW ...................................................................................................................................... 11
3.6
TELEPHONY CALL CONTROL ........................................................................................................................ 11
4
INTER-PLANE INTERFACES ....................................................................................................................... 13
4.1
MANAGEMENT-MANAGEMENT PLANE ......................................................................................................... 14
4.2
CONTROL-CONTROL PLANE .......................................................................................................................... 14
4.3
SWITCHING-SWITCHING PLANE..................................................................................................................... 14
4.4
ADAPTATION-ADAPTATION PLANE ............................................................................................................... 14
4.5
ADAPTATION-SWITCHING PLANE .................................................................................................................. 15
4.6
ADAPTATION-CONTROL PLANE .................................................................................................................... 15
4.7
ADAPTATION-MANAGEMENT PLANE ............................................................................................................ 16
4.7.1
Configuration Management ................................................................................................................. 16
4.7.2
Fault Management ............................................................................................................................... 17
4.7.3
Performance Management ................................................................................................................... 17
4.7.4
Security Management .......................................................................................................................... 17
4.7.5
Interfaces ............................................................................................................................................. 18
4.8
SWITCHING-CONTROL PLANE ....................................................................................................................... 18
November 3, 1998
MSF Confidential
iv
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
4.9
SWITCHING-MANAGEMENT PLANE ............................................................................................................... 19
4.9.1
Configuration Management ................................................................................................................. 19
4.9.2
Fault Management ............................................................................................................................... 19
4.9.3
Performance Management ................................................................................................................... 19
4.9.4
Security Management .......................................................................................................................... 19
4.9.5
Accounting Management ..................................................................................................................... 20
4.9.6
Interfaces ............................................................................................................................................. 20
4.10
5
CONTROL-MANAGEMENT PLANE.................................................................................................................. 20
4.10.1
Configuration Management ................................................................................................................. 20
4.10.2
Fault Management ............................................................................................................................... 20
4.10.3
Performance Management ................................................................................................................... 21
4.10.4
Security Management .......................................................................................................................... 21
4.10.5
Accounting Management ..................................................................................................................... 21
4.10.6
Interfaces ............................................................................................................................................. 21
EXAMPLES OF THE ARCHITECTURE ...................................................................................................... 21
APPENDIX A. ACRONYMS AND DEFINITIONS............................................................................................... 24
APPENDIX B. EXAMPLE MGCP AND VOICE/ATM CALL FLOW ............................................................... 26
November 3, 1998
MSF Confidential
v
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
The following people and organizations contributed to version 1.0 of this document.
David Auerbach
Cisco
Bill Buckley
Cisco
Doug Cardy
MCI Worldcom
Allen Holmes
MCI Worldcom
Christian Huitema
Bellcore
Rajesh Kumar
Cisco
Kevin Lio
Cisco
Morgan Littlewood
Cisco
Dave McDysan
MCI Worldcom
Petros Mouchtaris
Bellcore
Sunny Mahant
Cisco
Rob Maidhof
MCI Worldcom
Kelvin Porter
MCI Worldcom
Derek Smyk
Bellcore
Lee Thomas
MCI Worldcom
Wendy Wong
MCI Worldcom
November 3, 1998
MSF Confidential
vi
1
INTRODUCTION
This document provides an initial architectural framework for the work of the Multiservice Switching Forum (MSF).
Its goal is to define the elements of a Multiservice Switching System (MSS) that supports services such as ATM, FR,
IP, voice, circuit emulation and video. MSF Implementation Agreements define the requirements of the interfaces
between components of a MSS. The organization of the document is as follows:
Section 1: Defines the purpose as well as the technical and business objectives of the MSF
Section 2: Describes the multi-plane model of the MSF architecture
Section 3: Describes the significant requirements that will guide MSF Implementation Agreements
Section 4: Describes the requirements of the inter-plane interfaces defined by the MSF architecture
Section 5: Provides some examples of the architecture
1.1
Forum Purpose
The purpose of the Multiservice Switching Forum (MSF) is to:

define an architecture that separates the control and user/data plane aspects of an ATM-capable Multiservice Switching System (MSS) and establishes a framework which can be easily extended to support new
adaptation and switching plane and control functions

define a set of open intra-switch interfaces based upon this architecture document and promote Implementation Agreements for these interfaces that allow service providers to deploy ATM-capable Multiservice
Switching Systems composed of best-of-breed components from multiple vendors
1.2
Definitions
This document employs the following terminology:

Must, Shall, or Mandatory — the item is an absolute requirement of the Implementation Agreement.

Should — the item is highly desirable.

May or Optional — the item is not compulsory, and may be followed or ignored according to the needs of
the implementers.
1.3
Architecture Objectives
The architecture of the Multiservice Switching System is intended to meet the following technical objectives:

Support integrated voice, video, data, and multimedia switching and call processing

Suitable for high availability networks

Scalable to large port counts, aggregate bandwidth and high transaction rates

Support a broad range of ATM-capable, reserved bandwidth, guaranteed QoS connection types

Define a consistent set of protocols for controlling and interworking services, including voice, ATM
PVCs/SVCs, Frame Relay PVCs/SVCs, IP, etc. over a range of media

Support the development of more efficient and flexible networks
The architecture is also intended to support the following business goals:

Allow competitive procurement of modular subsystems rather than an entire MSS

Employ standard interfaces wherever feasible
MSF Confidential
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0

Separate call processing from the switch fabric using open interfaces

Facilitate vendor, carrier, or third party development of application software

Exploit commercially available computer technology (hardware and software)
1.4
Relevant Standards Bodies
The Implementation Agreements, reached in the Multiservice Switching Forum, leverage the relevant standards
produced by standards bodies and other forums. The following is a list of the standards bodies the Multiservice
Switching Forum acknowledges as leaders in their respective standards activities.

International Telecommunications Union - Telecommunications Standardization Sector (ITU-T)

ATM Forum (ATMF)

Internet Engineering Task Force (IETF)

Frame Relay Forum (FRF)

American National Standards Institute (ANSI)

European Telecommunications Standards (ETSI)

Network Management Forum (NMF)

Optical Internetworking Forum (OIF)

Bellcore Generic Requirements

Object Management Group (OMG)
The intent of the Multiservice Switching Forum is to specify Implementation Agreements which complement the
standards developed by the standards bodies listed. The MSF architecture for multiservice switching systems shall
support all the relevant UNI, NNI, and network management standards developed by these standards bodies.
Implementation agreements may be submitted to different bodies involved in the ratification of Implementation
Agreements and conformance tests to facilitate multi-vendor interoperability.
2
MULTI-PLANE SYSTEM ARCHITECTURE
A multi-plane system model has been selected as the basis of the Multiservice Switching System architecture. The
architecture employs a layered model, clearly identifying the areas where Implementation Agreements are necessary.
Whenever possible, the model uses standards from the organizations mentioned earlier.
Figure 1 illustrates the Adaptation, Switching, Control, Applications and Management Planes of the architecture.
Starting from the bottom of the figure, the Adaptation Plane supports the physical interface to a user or another
network element. The MSF uses ATM Adaptation Layer (AAL) protocols to define interconnection via an ATMcapable Switching Plane as shown in the figure. The Control Plane involves standard signaling and routing
protocols, while the Applications Plane covers all other protocols. Subsequent sections detail the functions and
interfaces involved in each plane. The architecture covers interfaces and protocols between controllers of various
types in the Control Plane and the ATM Switching Plane and ATM Adaptation Plane as shown via the dashed lines
in the figure. Each specific Adaptation Plane element (e.g., a voice or an ATM port) should be controlled by only
one protocol. This decision simplifies the controller design, since each controller utilizes the same interface for a
specific Adaptation Plane element. The scope of the MSF also includes use of protocols between Control Plane
processors, for example, use of signaling between a voice/SS7 controller and an ATM/SVC controller as shown in
the middle of the figure. See Section 4 for details on the inter-plane interfaces.
November 3, 1998
MSF Confidential
2
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Standard IN/Signaling APIs, Interfaces, and Protocols
Control
Plane
IP/MPLS
Controller
Switching
Plane
Adaptation
Plane
Voice/SS7
Controller
ATM/SVC
Controller
...
ATM-Capable Fabric
TCP/IP
External
Interfaces/
Protocols
Video
Voice
TDM
FR
ATM
Management Plane
Applications
Plane
...
Standard Physical and Logical Interfaces
Figure 1. Scope of the Multiservice Switching Architecture
Adaptation Plane resources are either dedicated to a single controller, or shared between controllers.
Examples of dedicated resources are:

Time slots on TDM ports

VPI/VCI values on an ATM port

DLCI values on a FR port

Dedicated bandwidth
Examples of shared resources are:

Interface bandwidth

Conference bridges

Tone receivers

Buffers
The protocol used to control a particular adaptation function is dependent upon the required functionality, complexity, and performance. For example, the architecture strives to make control of native ATM and ATM-based
adaptation protocols (e.g., frame relay and circuit emulation) as efficient as possible. Where an adaptation function
has a more complex and evolving set of requirements (e.g., voice and IP), adaptation specific protocols may be
required. A common protocol should be employed to control a specific type of adaptation device. If different
protocols are defined to control comparable adaptation functions (e.g., Voice/ATM and Voice/IP), then the MSF's
specifications should encode the parameters in the same format.
The port-to-port service provided by the Multiservice switch is a combination of the Adaptation and Switching
Planes as established via the Control Plane.
November 3, 1998
MSF Confidential
3
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
2.1
Adaptation Plane
The Adaptation Plane is responsible for providing access to a large variety of user and trunk interfaces that a
Multiservice Switching system may support. Typical functions of the Adaptation Plane are:
a)
Processing voice, data, video streams to create cells for the Switching Plane to transport. This includes
using ATM Adaptation Layer (AAL) standards to define the required functions, as well as performing
bearer path services like echo cancellation or voice compression.
b) Capturing signaling information from each port and either processing it locally and/or passing the information to the Control Plane. This includes capturing and passing D channel and SS7 signaling information as well as monitoring for in-band events such as DTMF tones on voice interfaces.
c)
Provides service-specific functions that do not directly affect the bit stream on the interface. For example, queue management and policing are best implemented in the Adaptation Plane.
d) Negotiating connection and adaptation parameters, such as bit rate and codec type, with the peer Adaptation Plane Element at the far-end Multiservice Switching System. For example, the H.245 protocol
controls video or voice coding algorithms and bit rates at call establishment time and on the fly during
the connection. The Adaptation Plane shall provide control and reporting functions to the Control and
Management Planes appropriate for these negotiation protocols.
2.2
Switching Plane
The Switching Plane is responsible for the cell switching function within the Multiservice Switching System.
Functions of the Switching Plane include:
a)
Supporting a multiplicity of adaptation elements under the domain of a single controller. This should
include remotely located adaptation elements reliably interconnected via standard interfaces like
SONET/SDH Automatic Protection Switching (APS).
b) Providing an ATM-cell-based interface to the Adaptation Plane. When the switching and Adaptation
Plane are implemented as separate physical elements, the interface should be based upon standard
physical interfaces, such as SDH or SONET.
c)
Switching cells or flows based on VPI/VCI fields
d) Queuing, servicing, and performing cell header functions based on VPI/VCI values, the ATM Service
Category (i.e., CBR, rt-VBR, nrt-VBR, UBR, ABR), and the traffic parameters of the ATM connection
e)
Replicating cells for point-to-multipoint (pt-mpt) connections
f)
Performing ABR functions like EFCI marking and Resource Management (RM) cell processing.
g) Providing a common control interface to multiple controllers.
h) Partitioning and sharing resources within the switch and on trunks between the multiple controllers
2.3
i)
Supporting a multiplicity of switching elements under the domain of a single controller. Support
should include reliably interconnecting, via standard interfaces like SONET/SDH Automatic Protection
Switching (APS), remotely located switching elements.
j)
Merging cells in a multipoint-point (mpt-pt) configuration in support of MPLS
Control Plane
The Control Plane is responsible for the routing of traffic and the allocation of Switching Plane, Adaptation Plane
and Applications Plane resources within the switching system. Specific functions of the Control Plane include:
a)
Routing & rerouting of traffic between switching complexes within a node as well as connections between multiservice switching nodes
November 3, 1998
MSF Confidential
4
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
b) Controlling the establishment of VPI/VCI mappings between port interfaces connected via the Switching Plane
c)
Assigning bandwidth allocation and queuing parameters to each VPI/VCI mapping
d) Controlling the Adaptation Plane functions
e)
Terminating and originating signaling from Trunk, NNI and UNI ports in conjunction with the Adaptation Plane
f)
Providing APIs and protocol interfaces to the Applications Plane
g) Supporting a variety of signaling interfaces for voice, data, video services, including SS7, Q.931,
H.323, etc.
h) Performing admission control and traffic engineering (e.g., MPLS) for the network.
i)
Providing connection-level statistics, Call Detail Records and alarms
The Control Plane should be modular and may include several, independent controllers. For example, it may include
separate controllers for Voice/SS7, ATM/SVC, and even IP/MPLS services as shown in Figure 1.
2.4
Applications Plane
The Applications Plane is responsible for services not related to the switching or queuing of traffic. The Applications
Plane is outside the scope of the MSF. Specific functions of the Applications Plane include:
a)
Messaging services such as email and voice mail
b) Processing services such as automatic speech recognition and credit card processing
c)
Directory enabled services such as Freephone/8xx number translation, local number portability, single
number follow-me services for voice
d) CLASS services such as call waiting, call forwarding, conference calling for voice
e)
Virtual Private Network and Centrex services for voice & data
f)
IP naming and addressing services including DNS, DHCP, Radius services
g) Value-added IP telephony services such as virtual second line, web-800
2.5
Management Plane
The Management Plane includes management functions and interfaces for the Adaptation Plane, Switching Plane,
Control Plane, and Applications Plane within this Multiservice Switching System. These functions, commonly
known as Element Layer (EL) functions in the context of TMN (Telecommunication Management Network) will
further enable higher layer management functions including Element Management Layer (EML), Network
Management Layer (NML), Service Management Layer (SML), and Business Network Layer (BML). Since the
implementation of those higher layer management functions are handled outside of the multiservice switching
system, they are not considered within the scope of this document. Section 4 contains detailed requirements for
managing the Adaptation, Switching, and Control Planes. Furthermore, a SNMP interface shall be provided
consistently across the Adaptation, Switching, and Control Plane for management purposes. The use of CORBAbased management services and interfaces shall be considered as a future requirement.
The approach taken for management of the Adaptation and Switching Planes maps Bellcore GR-1248-CORE, Issue
2.x (Generic requirements for Operations of ATM Network Elements) requirements for an ATM switching system
requirement sections into the respective sections using the following criteria:

Physical layer, AAL layer, and UNI/NNI interface layer management functions map to the Adaptation
Plane

ATM VP and VC management functions, map to the Switching Plane
November 3, 1998
MSF Confidential
5
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Typical functions of the Management Plane are:
a)
Configuration management of the physical layer, AAL layer, UNI/NNI interface layer, VP/VC layer,
and the virtual switch controllers to provision and update their respective parameters. Also included are
Database backup and restore functions and software download support
b) Fault management functions such as alarm surveillance, fault localization and testing.
c)
Performance management functions such as monitoring of physical transport facilities, protocol monitoring, VP/VC performance monitoring, and network data collection.
d) Security management functions in terms of identification and authentication of users, system access
control, resource access control, security log, data/system integrity, and administration.
e)
3
Accounting management functions in terms of usage based billing are performed for ATM/Frame Relay PVCs and SVCs, IP, voice, and other multimedia applications.
SYSTEM REQUIREMENTS
This section summarizes the principal system and protocol requirements that will be used as the basis for creating
further Implementation Agreements.
3.1
System Modularity
The architecture meets the objective of modularity by clearly defining groupings of related functions with welldefined interfaces and functional requirements. Figure 2 illustrates the principal Multiservice switching system
components covered by the MSF. At the bottom of the figure, a switching complex comprised of an ATM-capable
switching fabric and ports supporting ATM, voice, and other protocols acts under the control of a processor complex
comprised of one or more processors.
The switching complex contains ports implementing Adaptation Plane functions connected via an ATM-capable
switching fabric. Section 3.5 provides examples of switching complexes. The switching complex connects to a
cluster of one or more controller processes in a processor complex.
The processor complex includes computers running software that implement functions in the Control Plane. The
protocol(s) and interface(s) between the controllers in the processor complex and the processors in the switching
complex are the principal topic addressed in the Multiservice Switching Forum in its initial Implementation
Agreements.
As illustrated in Figure 2, the Management Plane covers augmentations necessary for monitoring and control of the
Switching and Adaptation Planes. The scope of the MSF also includes the specification of particular uses of
protocols between controller processes as shown within the control bubble of the figure.
November 3, 1998
MSF Confidential
6
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Processor
Complex
Management
Plane
Controller
Process
Controller
Process
Control
Plane
Signaling
& Other
Protocols
Protocol(s)
and Interface(s)
Addressed by
the MSF
Augmentations
to Management
Protocols
Switching
Complex
ATM-Capable Fabric
Management
Plane
Voice
Port
ATM
Port
Other
Port
Switching
Plane
Adaptation
Plane
Figure 2. Multiservice Switching and Controller Complex Interface and Protocols
3.2
Protocol Requirements
The majority of MSF Implementation agreements will cover the specification of protocols that allow the interconnection of processing and switching complexes and the planes implemented by them. The MSF architecture specifies a
well-structured and complete set of protocols that allow separate modules to cooperate as a single system. Where
feasible, existing or emerging industry standards should be used. Each protocol should fit into a protocol architecture that is consistent in approach, ensures completeness and does not unduly impact the cost, complexity or
technical feasibility of the whole system.
Given the above goals, the interface between the processing complex and the switching complex will not be a single
protocol, but will be a suite of protocols that may share a common communications infrastructure. This model allows
reuse of protocols being defined by other standards organizations, but does not impose a significant additional cost
burden. This modular usage of existing and emerging protocols is expected to enable rapid development and
refinement of Implementation Agreements.
As an example, Figure 3 illustrates the general structure of the target architecture for the protocols operating over the
interface between the switching complex and the processor complex. Starting from the bottom, the physical, link,
and network layer protocols should meet the requirements stated above. Candidate physical and link layer protocols
are 100 Mbps/1 Gbps Ethernet and ATM/AAL5. The unshaded portions of the protocol stack are based upon
standards. The lightly shaded parts of the protocol stack are the initial focus of the MSF. Additional protocols may
be added in the future to support services such as video distribution and conferencing. The MSF plans to define
VoATM extensions to cover capabilities and cases not defined in MGCP.
November 3, 1998
MSF Confidential
7
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
TRANSPORT
IP
VOICE
Voice (POTS/PRI/..) over
Switching
Fabric
Frame
Relay
ATM
CES
...
TDM
ATM
...
IP
COPS
MPLS
IS-IS
BGP
VoATM Extensions
Adaptation Extensions
MGCP
VSI
IP
...
Controlled
Elements
Controlling
Protocols
TCP
UDP
IP
Communications
Infrastructure
LLC/SNAP
ATM/AAL5
Ethernet
Physical Layer (e.g., OC12/STM4, OC3/STM1)
10/100/1,000 Mbps
Figure 3. Controller-Switch Interface Protocol Stack Structure
Requirements on the lower-level communications infrastructure protocol(s) and interface(s) between the switching
complex and the processor complex are:

Standard at the physical, link, and network layer

Secure communication between the controller and the Switching/Adaptation Plane complexes

High throughput

Low latency

Easy to parse

Support for redundant physical interfaces

Remotely manageable

Widely implemented on computing platforms

Operating system and machine independent
The Virtual Switch Interface (VSI) protocol provides for control of the Switching Plane and selected portions of the
Adaptation Plane by the Control Plane. Given this role, the VSI protocol is required to implement the following
functions:


Connection Processing
-
support for pt-pt, pt-mpt, and mpt-pt connection types
-
support for all ATM Forum and MPLS connection types
-
extensible support for other connection types
-
distributed connection setup/teardown scheme for scalability
-
pipelined call setup support for high speed processing
-
support for connection diagnostics
Support for multiple services
November 3, 1998
MSF Confidential
8
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0




-
switch supports multiple independent controllers
-
allow implementation of multiple independent services on single switching element
-
allows controller function to be external to the switching elements
-
supports multiple QoS types
-
extensible support for other service types
-
controller configurable service type policy (including oversubscription)
Resynchronization
-
efficient resynchronization between controller and switch
-
hitless resynchronization where controllers can be replaced/restarted without connection loss
-
support of full redundancy of controller and switch
Statistics
-
Flexible method of selecting statistics per connection
-
Efficient collection of billing statistics and real-time performance monitoring
Controller/Switch Independence
-
Control independent of network protocol/service
-
Control independent of switch hardware
-
Automatic switch topology discovery
Miscellaneous
-
Flexible yet efficient message formats
-
Transaction-level flow control
-
Support for clock synchronization between the Control and Switching Planes.
-
Passthrough protocol to support adaptation extensions
-
Support for automatic protocol version selection
-
Enable configurable trap filtering
The Media Gateway Control Protocol (MGCP) allows the Control Plane to control the voice functions of the
Adaptation Plane. Given this role, MGCP is required to support the following functions:



Termination of user signaling for voice

Detection of signals (off hook, on hook transitions)

Detection of dialed digits

Downloading of dialing plans
Telephony gateway control function

Connection establishment

VPI/VCI selection
Codec capability negotiation

Compression parameters

Encoding parameters
November 3, 1998
MSF Confidential
9
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
3.3
Separation of Bearer and Control
A fundamental concept in the MSF architecture is the separation of the data flows containing user, or bearer,
information from those flows containing control, or signaling information. ATM employs Virtual Channel
Connections (VCCs) separate from bearer VCCs to carry control plane information. As illustrated in Figure 4, the
MSF architecture requires that the switching complex either:
1.
redirect network control (e.g., signaling and routing) information to the Control Plane,
2.
pass end-to-end control transparently between Adaptation Plane ports,
3.
terminate generic ATM link control flow within the Switching/Adaptation Plane.
The means to intercept, or backhaul signaling is defined further in section 4.
Processor
Complex Signaling
& Other
Protocols
Control
Bearer
Switching
Complex
Port
Fabric
Port
Port
Port
Figure 4. Separation of User/Bearer and Control Information by the Multiservice Switching Architecture
3.4
Intra-System Interfaces
The MSF objectives require that the intra-system physical interfaces are standards-based, scalable and sufficiently
robust for high availability systems The recommended physical layer interfaces are based upon ITU-T and ANSI
Recommendations. The primary interfaces for user traffic shall be based on SONET/SDH interfaces with the
appropriate usage of overhead facilities. MSF Implementation Agreements will document the use of overhead
facilities. This includes the use of Automatic Protection Switching (APS) as defined in the SONET/SDH K1/K2
bytes for reliable connection of remote switching complex equipment as part of a single node.
Additional local interconnect options that provide significantly better cost/performance characteristics may be
considered in the future. Control and signaling interfaces may use the same SONET/SDH interfaces or may use
separate 10/100 Mbit/s Ethernet interfaces.
The recommended link layer interface within the switching system shall be ATM and in accordance with the ITU-T
and ATM Forum recommendations. The use of ATM shall also include use of the standard ATM Adaptation
November 3, 1998
MSF Confidential
10
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Layers.
3.5
Single Node View
In order to achieve the benefits of the Multiservice Switching Forum architecture, it is required that a network
operator shall be able to configure a node from equipment procured from several vendors. In order to meet the
scalability requirements, the MSF Implementation Agreements shall enable a single controller complex to make
several Switching and Adaptation Plane elements appear as one in terms of intranodal connectivity. This requirement applies to both the Control and Management Plane views of the system
The MSF architecture defines a node as a set of adaptation ports capable of being configured and connected via a
single control computer complex. Figure 5 illustrates this single node view concept for a Control Complex and three
switching complexes labeled A, B, and C. The figure shows an example intranodal connection between switching
complexes A and C.
Processor
Complex
Multiservice
Switching
Node
Switching
Complex
C
Switching
Complex
A
Switching
Complex
B
Intranodal Connections
Figure 5. Single Node View of a Control Complex and Several Multiservice Switching Machines
3.6
Telephony Call Control
Telephony services may be supported across a Multiservice network using several options for establishing the voice
path including SVCs, IP or VP PVCs. The MSF architecture for telephony services is based on the Media Gateway
Control Protocol (MGCP) architecture. MGCP and any associated backhaul protocol are the protocols used between
the Adaptation Plane (i.e. the MGCP Telephony Gateway) and the Control Plane (i.e., SS7/Voice Controller or the
MGCP Call Agent). In this architecture, MGCP provides a control capability and certain signaling capabilities.
Where required, the backhaul protocol transports signaling information, such as Q.931 messages, between the
Telephony Gateway and the Call Agent.
For each of the voice path establishment options, the Call Agent (CA) would perform call processing and interface
with the Application Plane (e.g. Intelligent Network). The Call Agent may use the services of an ATM/SVC or
IP/MPLS controller or may explicitly control the Switching Plane via VSI. A single Call Agent may be associated
with a portion of a MSS or a group of MSS's.
The following two figures describe a SVC-based architecture for voice over ATM. In both examples, the Call Agent
reacts to SS7 signaling using MGCP to control the telephony gateway. The originating Call Agent negotiates with
the Call Agent of the destination telephony gateway the parameters of the call.
November 3, 1998
MSF Confidential
11
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Figure 6 shows the case where the Telephony Gateway is responsible for establishing the ATM connections using
first party UNI signaling as defined by the ATM Forum 3.1 or 4.0 signaling specifications. After the Call Agent
signaling completes, the destination telephony gateway requests an ATM connection via first-party UNI signaling
from the ATM/SVC controller. The ATM/SVC controller establishes the gateway-gateway ATM connection over
the ATM network. Appendix B contains an example of a call flow diagram for this configuration.
Applications
Plane
TCAP
TCAP
SS7
CA to CA
SS7
Call Agent
Call Agent
Control
Plane
MGCP
PNNI
Controller
UNI
Switching
Plane
Adaptation
Plane
PNNI
VSI
ATM
Switch
Telephony
Gateway
MGCP
PNNI
Controller
VSI
UNI
ATM
Switch
Telephony
Gateway
Voice/TDM
Voice/TDM
Figure 6. UNI Control via ATM-Capable Telephony Gateways
Figure 7 shows how the call agent utilizes UNI proxy signaling as defined by in ATM Forum’s 4.0 signaling
specification for establishing ATM connections between telephony gateways. After the Call Agent signaling
completes, the destination Call Agent requests an ATM connection via proxy signaling from the ATM/SVC
controller. The ATM/SVC controller establishes the gateway-gateway ATM connection over the ATM network.
This mode may be used where it is not desirable to have a full SVC implementation on the Telephony Gateway.
November 3, 1998
MSF Confidential
12
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Applications
Plane
TCAP
TCAP
SS7
Call Agent
CA to CA
Proxy
Signaling
Control
Plane
MGCP
PNNI
Controller
Call Agent
Proxy
Signaling
Adaptation
Plane
MGCP
PNNI
Controller
PNNI
VSI
Switching
Plane
SS7
VSI
ATM
Switch
ATM
Switch
Telephony
Gateway
Telephony
Gateway
Voice/TDM
Voice/TDM
Figure 7. Proxy Control via Call Agent for ATM-Capable Telephony Gateways
4
INTER-PLANE INTERFACES
A Multiservice network requires the interaction of multiple switching systems operating at several planes in order to
deliver a complete set of user services. Many of the protocols and interfaces are defined by other standards
organizations. In particular, Control Plane to Control Plane protocols are defined by the ATM Forum (PNNI), ITUT (SS7, ISUP, B-ISUP) and the IETF (MPLS, OSPF and BGP). Adaptation Plane to Adaptation Plane protocols are
also defined by various bodies. The role of the MSF is to aid in the selection of protocols and interfaces to be used
between systems in an intra-nodal environment and to specify the protocols and interfaces used within a switching
system.
The Multiservice Switching Forum intentionally limits the scope to intra-system interfaces between the Management,
Control, Switching and Adaptation Planes as shown in Table 1. The cells in the table marked with MSF are within
the scope of the Forum. The other cells are marked with the names of other bodies associated with the standardization of these interfaces.
Table 1. Scope of the MSF Regarding Inter-Plane Interfaces and Protocols
1
Management
Control
Switching
Adaptation
Management
NMF
MSF
MSF
MSF
Control
MSF
MSF1,ITU-T,
ATMF, IETF
MSF
MSF
Switching
MSF
MSF
MSF
MSF
Adaptation
MSF
MSF
MSF
ITU-T, FRF, IETF
Only extensions as required within an MSS
November 3, 1998
MSF Confidential
13
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
The following paragraphs summarize the requirements of each of the inter-plane interfaces. The order of the interplane interface descriptions is as follows:
Management-Management Plane
Control-Control Plane
Switching-Switching Plane
4.1

Adaptation-Adaptation Plane

Adaptation-Switching Plane

Adaptation-Control Plane

Adaptation-Management Plane

Switching-Control Plane

Switching Management Plane

Control-Management Plane
Management-Management Plane
The Management-Management Plane interfaces operate between the MSS element management system and the
higher level management systems and are within the scope of bodies such as the Network Management Forum
(NMF), OMG, and the ATM Forum. The MSF shall work to ensure that its Implementation Agreements support the
standards defined these other bodies.
4.2
Control-Control Plane
The Control-Control Plane interfaces and protocols operate between switching systems and are within the scope of
the following bodies:
ATM Forum (UNI, PNNI)
IETF (MPLS, OSPF, BGP)
ITU-T (DSS1, DSS2, SS7, ISUP, B-ISUP)
The MSF shall work to ensure that the routing and connection control protocols specified by these bodies can be
supported by the MSF architecture. Similarly, the MSF shall work to support the full set of UNIs and NNIs defined
by these bodies.
4.3
Switching-Switching Plane
The Switching-Switching Plane interfaces exist between switching elements within a switching system and should
use ATM-based interfaces as defined by the ATM Forum and the ITU-T to support multi-vendor configurations.
These interfaces shall use standard physical layer interfaces such as OC-3/STM-1, OC-12/STM-4 and OC-48/STM16. It is also expected that physical interfaces specified by the Optical Internetworking Forum may also be used.
4.4
Adaptation-Adaptation Plane
The Adaptation-Adaptation Plane interfaces specify the end to end bearer protocols used by the various services. In
all cases the bearer protocol will be ATM based at the link level. The bearer protocols have been and will continue to
be standardized by other bodies. The MSF shall work to support the full set of bearer capabilities that a Multiservice
Switching System is expected to support. The following list summarizes key aspects of bearer protocols for common
services:

TCP/IP
November 3, 1998
MSF Confidential
14
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0




IP over RFC 1483 over AAL5

MultiProtocol Label Switching (MPLS) over AAL5
Voice/IP

PCM (G.711), ADPCM (G.726), CELP (G.729), or MP-MLQ (G.723.1) encoding

RTP/UDP or H.323 bearer protocol stack

IP (RFC 1483) or MPLS over AAL5
Voice/ATM

PCM (G.711) Encoding

AAL1, AAL2, or AAL5
Structured or Unstructured Circuit Emulation Service (CES)



Frame Relay

FRF.5 (Network Interworking) over AAL5

FRF.8 (Service Interworking) over AAL5
ATM


4.5
AAL1 with SRTS, synch, or adaptive clock recovery
Transparent to all adaptation layers
Video

Video On Demand (VOD) over AAL5

Video over AAL1

Video over IP using RTP/UDP/IP (RFC 1483 or MPLS)
Adaptation-Switching Plane
The Adaptation and Switching Planes are coordinated by the Control Plane to ensure that at least the following
occur:

Allocation of transmission rate

Assignment of VPI/VCI values

Specification of transmitting and receiving physical interfaces

Selection of ATM service category
The interface between the Adaptation-Switching Planes is an ATM-based interface using ITU-T and ATM Forumdefined Physical and Link layers. The MSF may specify the use of physical layer facilities such as the K1/K2 bytes
to provide Automatic Protection Switching (APS).
4.6
Adaptation-Control Plane
The Adaptation Plane shall support a range of service interfaces including UNIs and NNIs for Voice, IP, Frame
Relay, Circuit and ATM services. Each service has a distinct set of attributes and signaling requirements that must be
supported by the Adaptation-Control Plane interface. The MSF shall define a set of Adaptation-Control Plane
protocols that allow the support of this full range of services. These protocols shall enable both the relaying of
service signaling information as well as control of the Adaptation Plane functions.
November 3, 1998
MSF Confidential
15
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
The Adaptation-Control Plane interface includes the means to intercept, relay, and redirect at least the following
types of signaling for each service type:

TCP/IP


Voice/IP


DTMF, PRI, SS7, or robbed-bit signaling
Frame Relay


Robbed bit, DTMF or out-of-band signaling in CES format
Voice/TDM


H.323 or SIP control protocol stack
Voice/ATM


Dynamic routing information
DLCI=0 UNI/NNI Signaling
ATM

VPI/VCI=0/5 for UNI/NNI Signaling

VPI/VCI=0/16 for ILMI

VPI/VCI=0/18 for PNNI
For voice services, the Control Plane is expected to use extensions to the IETF draft for a Media Gateway Control
Protocol (MGCP) to manage the Adaptation Plane for voice interfaces. The protocol is designed to provide a
scalable mechanism to:

Establish voice or video connections, including the ability to create, modify, and delete connections

Monitor connections for events (like tones, off hook, etc.), including the ability to request information
from the Adaptation Plane and a response

Manage endpoints such as ports as well and resources such as echo cancellers, tone detectors, and
bandwidth

Backhaul signaling information from the Adaptation Plane to the Control Plane, including D channel,
facility associated SS7, and channel associated signaling (CAS)
The Adaptation-Control Plane protocol includes the capability to negotiate connection and adaptation parameters,
such as bit rate and codec type. For example, the Session Descriptor Protocol (SDP) aspect of MGCP controls
video or voice coding algorithms and bit rates at call establishment.
4.7
Adaptation-Management Plane
Extensive reference to the Bellcore document (GR-1248-CORE) is used here to leverage the industry standards and
agreements. Since the Bellcore document takes a total switching system view (without partitioning into the different
planes), some effort is required here to properly allocate and map those functions into the respective Switching and
Adaptation Plane. The management functions are categorized into five functional areas as follows.
The architecture makes the assumption that relevant management functions pertaining to the physical (e.g., DSx and
SONET), adaptation (AAL) and logical interface levels (e.g., UNI, NNI) are handled at the Adaptation Plane.
Whereas, the ATM VP and VC levels are managed in the Switching Plane.
4.7.1 Configuration Management
Key functions include:
November 3, 1998
MSF Confidential
16
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0

Detect and report memory updates reflecting changes in the configuration of the resources within the
Adaptation Plane that are transparent to the external management system environment.

Notify the external management system when new resources (e.g., ATM/FR cards, voice modules, etc.)
have been installed/initialized and are available to the management system for subsequent provisioning.

Configuration of physical and logical interfaces (e.g., UNI, NNI)

Backup and restoration of database or memory to allow recovery from the loss of data due to factors
such as human error, power failure, hardware failure, and software bugs.

Software download support which allows downloading of replacement software, software enhancements, and software patches.
Reference: Bellcore GR-1248-CORE, Section 5
4.7.2 Fault Management
Key functions include:

Alarm surveillance functions which involve in the detection of faults/defects in the physical (DSx,
SONET/SDH), and logical UNI/NNI interfaces, and declaration of failures

Fault localization and testing functions that are used to isolate failures down to the smallest repairable/replaceable unit of hardware/software.
Reference: Bellcore GR-1248-CORE, Section 6
4.7.3 Performance Management
Key functions include:

Monitoring of physical transport facilities for DSx interfaces, SONET (or SDH) interfaces of STS-1,
STS-3c, STS-12c, STS-48c, etc.

Protocol monitoring of the ATM layer (e.g., cell discarded due to HEC violations or cell header errors)
and ATM Adaptation Layers (AALs).

Network data collection for traffic load measurements on each UNI and NNI at both ingress and egress
points.

Continuously report performance measurements, or in response to a poll from the external management
system.
Reference: Bellcore GR-1248-CORE, Sections 7, 9, and 10.
4.7.4 Security Management
The security functions shall apply uniformly to safe guard the resources within the Adaptation, Switching, and
Control Planes. Key functions include:

Identification and authentication of users (e.g., user name and password checks)

System access control including session time-out and limiting the number of password attempts.

Resource access control to make sure that users are authorized to perform the functions they request.

Security log (audit) provides the ability to examine an audit trail when a security problem is suspected.

Security administration functions (e.g., All users other than the administrator shall be denied permission to certain functions).
November 3, 1998
MSF Confidential
17
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Reference: Bellcore GR-1248-CORE, Section 11
4.7.5 Interfaces
The following are relevant to the Adaptation Plane:
4.8

IETF RFCs 1213, 1573, 1406, 1407, 1595, 1695, ATM Forum PNNI MIB

ATM Forum ILMI MIB

ATM Forum M4 Interface Specifications
Switching-Control Plane
The Control Plane uses the MSF-VSI-1.0 Implementation Agreement to control the Switching Plane. The Virtual
Switch Interface (VSI) supports the following functions:





Connection Processing
-
support for pt-pt, pt-mpt, and mpt-pt connection types
-
support for all ATM Forum and MPLS connection types
-
extensible support for other connection types
-
distributed connection setup/teardown scheme for scalability
-
pipelined call setup support for high speed processing
-
support for connection diagnostics
Support for multiple services
-
switch supports multiple independent controllers
-
allow implementation of multiple independent services on single switching element
-
allows controller function to be external to the switching elements
-
supports multiple QoS types
-
extensible support for other service types
-
controller configurable service type policy (including oversubscription)
Resynchronization
-
efficient resynchronization between controller and switch
-
hitless resynchronization where controllers can be replaced/restarted without connection loss
-
support of full redundancy of controller and switch
Statistics
-
flexible method of selecting statistics per connection
-
efficient collection of billing statistics and real-time performance monitoring
Controller/Switch Independence
-
control independent of network protocol/service
-
control independent of switch hardware
-
automatic switch topology discovery
November 3, 1998
MSF Confidential
18
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
4.9
Switching-Management Plane
Extensive reference to the Bellcore document (GR-1248-CORE) is used here to leverage the industry standards and
agreements. Since the Bellcore document takes a total switching system view (without partitioning into the different
planes), some effort is required here to properly allocate and map those functions into the respective Switching and
Adaptation Plane. The management functions are categorized into five functional areas as follows.
4.9.1 Configuration Management
Key functions include:

Detect and report memory updates reflecting changes in the configuration of the resources within the
Switching Plane that are transparent to the external management system environment.

Configuration of ATM VPs and VCs (i.e., switching fabric) for point-to-point and point-to-multipoint
connections.

Notify the external management system when new resources (e.g., new switching modules, etc.) have
been installed/initialized and are available to the management system for subsequent provisioning.

Backup and restoration of database or memory to allow recovery from the loss of data due to factors
such as human error, power failure, hardware failure, and software bugs.

Software download support which allows downloading of replacement software, software enhancements, and software patches on the switching resources or common equipment.
Reference: Bellcore GR-1248-CORE, Section 5
4.9.2 Fault Management
Key functions include:

Detection of ATM VP and VC defects (e.g., VC AIS and RDI signals)

Fault (alarm) notifications to the external management system

VP/VC testing functions such as loopback and continuity check using OAM cells

Fault localization and testing functions that are used to isolate failures down to the smallest repairable/replaceable unit of switching hardware/software
Reference: Bellcore GR-1248-CORE, Section 6
4.9.3 Performance Management
Key functions include:

VP/VC performance monitoring using PM OAM cells (for both segment and end-to-end connections)

Activation and deactivation of of PM OAM cell F4/F5 flows

Traffic load measurements on each VP and VC at both ingress and egress points.
Reference: Bellcore GR-1248-CORE, Sections 7-10.
4.9.4 Security Management
The security functions shall apply uniformly to safeguard the resources within the Adaptation, Switching, and
Control Planes. Key functions include:

Identification and authentication of users (e.g., user name and password checks)
 System access control including session time-out and limiting the number of password attempts.
November 3, 1998
MSF Confidential
19
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0

Resource access control to make sure that users are authorized to perform the functions they request.

Security log (audit) provides the ability to examine an audit trail when a security problem is suspected.

Security administration functions (e.g., All users other than the administrator shall be denied permission to certain functions).
Reference: Bellcore GR-1248-CORE, Section 11
4.9.5 Accounting Management
Key functions include:

Usage based measurements at VP/VC level for ATM/FR PVCs at both ingress and egress points.
Measurement counters include total frames/cells received/transmitted, cell received with CLP (cell loss
priority) set, cell received with CLP set due to UPC violation, frames received in excess of CIR, etc.

Generation of Call Detail Records (CDRs) for SVCs

Conversion of CDRs into AMA format (Note: This may also reside in an external function module)
Reference: Bellcore GR-1110-CORE
4.9.6 Interfaces
The following MIBs are relevant to the Switching Planes:

IETF RFCs 1213, 1573, 1406, 1407, 1595, 1695, ATM Forum PNNI MIB

ATM Forum M4 Interface Specifications
4.10 Control-Management Plane
The management of the Control Plane covers extensions to existing protocols where necessary.
The management functions are categorized into five functional areas as follows.
4.10.1 Configuration Management
Key functions include:

Administration of the office data for the support of routing and rerouting of traffic between switching complexes within a node as well as connections between multiservice switching nodes

Administration of the office data for the VPI/VCI mappings between port interfaces connected via the
Switching Plane

Administration of numbering plan for controllers

Automatic discovery, identification, and memory updates (removal or addition) of controllers

Status updates of the controllers and state management

Signaling link status monitoring
4.10.2 Fault Management
Key functions include:
-
Alarm surveillance for the controllers and signaling links
-
Testing of controllers and signaling links to enable fault sectionalization
November 3, 1998
MSF Confidential
20
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
-
Reporting of autonomous alarms and events
4.10.3 Performance Management
Key functions include:
-
Performance counter monitoring for controllers (voice, tag/MPLS, PNNI, etc.) including packets, bandwidth utilization, and traffic data
-
Logging of historical data
4.10.4 Security Management
The security functions shall apply uniformly to safeguard the resources within the Adaptation, Switching, and
Control Planes. Key functions include:

Identification and authentication of users (e.g., user name and password checks)

System access control including session time-out and limiting the number of password attempts.

Resource access control to make sure that users are authorized to perform the functions they request.

Security log (audit) provides the ability to examine an audit trail when a security problem is suspected.

Security administration functions (e.g., All users other than the administrator shall be denied permission to certain functions).
Reference: Bellcore GR-1248-CORE, Section 11
4.10.5 Accounting Management
Key functions include:

Generation of Call Detail Record (CDRs)

Storage of CDRs

Conversion of CDRs into AMA format (Note: This may also reside in an external function module)
4.10.6 Interfaces
The following MIBs are relevant to the Control Plane
5

IETF MPLS MIBs

ATM Forum ILMI, and PNNI MIB
EXAMPLES OF THE ARCHITECTURE
A switching complex is a general term that represents a broad range of implementations. A switching complex
includes the following types of ATM-capable devices:

a device which contains adaptation ports of only one type (e.g., voice) multiplexing onto a single ATM
trunk-side interface

a single module in a vendor switching system containing multiple adaptation port types with redundant
ATM trunk-side interface

an ATM edge switch supporting a variety of ATM and adaptation port types

a Digital Subscriber Liner Access Multilplexer (DSLAM)
 a large multi-module ATM core/backbone switch
November 3, 1998
MSF Confidential
21
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0

an ATM-based IP router or MultiProtocol Label Switching (MPLS) device
Figure 8 gives an example of the architecture with a single processor complex controlling several voice/ATM
multiplexers connected to a single ATM core switch. Note that in a simple multiplexer, the ATM-capable fabric
may only be a bus connecting voice/TDM port cards (indicated by a "V" inside a box) in the chassis providing
access to the ATM trunk-side port (indicated by an "A" inside a box) as illustrated in the voice/ATM multiplexers in
the left-hand slide of the figure. Within the node, the MSF architecture specifies the use of standard ATM interfaces.
A larger ATM switch, for example as shown in the right-hand side of the figure, has multiple ATM ports connected
via an ATM-capable switching fabric (indicated by an "X" inside a box). Standards define the physical and ATM
layer connections used intranodally, as well as trunk-side interfaces.
Signaling
& Other
Protocols
Processor
Complex
Voice/TDM
Interfaces
Multiservice
Switching
Node
V
A
V
ATM
Intranodal
Interfaces
V
A
A
A
A
ATM
Trunk
Interfaces
A
V
ATM Core
Switch
Voice/ATM
Multiplexers
Figure 8. Example of the MSF Architecture using Voice/ATM Multiplexers Connected to an ATM Switch
The next example depicted in Figure 9 shows how remote switching complexes are reliably connected and controlled
under the MSF architecture using standard interfaces. The node is composed of three separate physical locations:
two Voice/Ethernet/ATM multiplexers and a core ATM switch site connected via standard ATM over SONET
facilities. Initial Implementation Agreements shall define reliable interconnection using standard SONET Automatic
Protection Switching (APS) in a ring or point-to-point topology. The figure illustrates the case of one remote
multiplexer and the switch connecting to a multiservice switching node via a standard 2- or 4-wire SONET ring
through an external SONET Add Drop Multiplexer (ADM). The multiplexer in the lower left-hand corner of the
figure implements the SONET ADM ring functions internally. This elimination of additional equipment targets cost
reduction via reduction of network elements.
November 3, 1998
MSF Confidential
22
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
A
E
A
ADM
V
Signaling
& Other
Protocols
Processor
Complex
A
E
A
A
A
ADM
V
A
ADM
Intranodal
SONET
RING
ATM
Trunk
Interfaces
ATM Core
Switch
Site
A
Multiservice
Switching
Node
Remote Voice (V),
Ethernet (E), & ATM (A)
Add-Drop Multiplexers
Figure 9. Remote Switching Complexes Reliably Connected under Common Control
November 3, 1998
MSF Confidential
23
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
APPENDIX A. ACRONYMS AND DEFINITIONS
Acronym
Definition
AALn
ATM Adaptation Layer n
ABR
Available Bit Rate
ADM
Add Drop Multiplexer
ADPCM
Adpative Delta Pulse Code Modulation
AIS
Alarm Indication Signal
AMA
Automatic Message Accounting
ANSI
American National Standards Institute
API
Application Programming Interface
APS
Automatic Protection Switching
ATM
Asynchronous Transfer Mode
ATMF
ATM Forum
BGP
Border Gateway Protocol
B-ISDN
Broadband ISDN
B-ISUP
Broadband ISDN User Part
B-ISUP
B-ISDN Services User Part
BML
Business Management Layer
CAS
Channel Associated Signaling
CBR
Constant Bit Rate
CDR
Call Detail Records
CELP
Code Excited Linear Predictive
CES
Circuit Emulation Service
CLP
Cell Loss Priority
COPS
Common Open Policy Server (IETF)
DLCI
Data Link Connection Identifier (FR)
DSLAM
Digital Subscriber Line Access Multiplexer
DSS1
Digital subscriber Signaling System 1 (N-ISDN)
DSS2
Digital subscriber Signaling System 2 (B-ISDN)
DTMF
Dual Tone Multiple Frequency
EFCI
Explicit Forward Congestion Indication
EML
Element Management Layer
ETSI
European Telecommunications Standards Institute
FR
Frame Relay
FRF
Frame Relay Forum
GR
Generic Requirements
IAM
Initial Address Message
IETF
Internet Engineering Task Force
ILMI
Integrated Local Management Interface
IP
Internet Protocol
ISDN
Integrated Services Digital Network
IS-IS
Intermediate System-Intermediate System (Routing Protocol)
ISUP
ISDN Services User Part
ITU-T
International Telecommunications Union - Telecommuncations standardization sector
LLC/SNAP
Logical Link Control/Subnetwork Access Protocol
MGCP
Media Gateway Control Protocol
MIB
Management Information Base
MPLS
MultiProtocol Label Switching
MP-MLQ
Multi Pulse - Maximum Likelihood Quantizer
MSF
Multiservice Switching Forum
MSS
Multiservice Switching System
N-ISDN
Narrowband ISDN
NML
Network Management Layer
November 3, 1998
MSF Confidential
24
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
NNI
OAM
OCn
OIF
OMG
PCM
PM
PNNI
PRI
PVC
QoS
RDI
RFC
RM
RTP
SDH
SIP
SNMP
SONET
SRTS
SS7
STM-n
STS-n
SVC
TCAP
TCP
TDM
TMN
UBR
UDP
UNI
VBR
VC
VCI
VoATM
VP
VPI
VSI
Network Node Interface
Operations And Maintenance
Optical Carrier level n (SONET)
Optical Internetworking Forum
Object Management Group
Pulse Code Modulation
Performance Management
Private Network-to-Network Interface or Private Network Node Interface
Primary Rate Interface
Permanent Virtual Connection
Quality of Service
Remote Defect Indication
Request for Comment (IETF)
Resource Management
Real Time Protocol
Synchronous Digital Hierarchy (ITU-T)
Session Initiation Protocol
Simple Network Management Protocol (IETF)
Synchronous Optical Network (ANSI)
Synchronous Residual Time Stamp (AAL1)
Signaling System Number 7
Synchronous Transfer Module level n
Synchronous Transport Signal Level n
Switched Virtual Connection
Transaction Capabilities Applications Part (SS7)
Transmission Control Protocol (IETF)
Time Division Multiplexing
Telecommunication Management Network
Unspecified Bit Rate
User Datagram Protocol (IETF)
User-to-Network Interface
Variable Bit Rate
Virtual Channel (ATM)
Virtual Channel Identifier
Voice Over ATM
Virtual Path (ATM)
Virtual Path Identifier
Virtual Switch Interface
November 3, 1998
MSF Confidential
25
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
APPENDIX B. EXAMPLE MGCP AND VOICE/ATM CALL FLOW
This appendix provides an example of the call flows and message parameters as an illustration of the architecture. It
is not a final specification, but intended as an illustration of the minimum level of detail required in an Implementation Agreement for the purposes of supporting voice over ATM using the protocols defined in the MSF architecture.
B.1
CONVENTIONS
B.1.1 Call Flow Conventions
This section describes the abbreviations used in the call flows. Since the call flows employ multiple protocols,
please refer to the specifications or standard documents for more detailed definitions of the messages, commands,
IE(s) or parameters. For example, the SS7 IAM is defined in ITU-T Q763.
To minimize confusion, the abbreviations used in the call flows are the same as defined in their associated protocols.
For example, “CRCX” is defined in MGCP as the abbreviation of “CreateConnection” message.
To minimize the ambiguity, for some of the parameter descriptions, expansions are added to their abbreviations. For
example, “L” is defined in MGCP as the abbreviation for the “LocalConnectionOption” parameter. In the call flows,
“L-i” is used to represent the instance on the ingress side; whereas “L-e” represents the instance on the egress side.
B.1.2 Network Component Conventions
PSTN Network Components
Component
Description
Egress SS7 Ntwk Elem
The network component receives voice call requests from the Egress GW.
Ingress SS7 Ntwk Elem
The PSTN network element that sends the voice-call requests to the MSF network.
MSF Network Components
Component
Description
Egress GW
Egress Telephony Gateway
Egress MSF C
Egress Multiservice Switching Forum Controller
Egress MSF SW
Egress Multiservice Switching Forum ATM Switch
Egress MGCP CA
Egress Media Gateway Control Protocol Call Agent
Ingress GW
Ingress Telephony Gateway
Ingress MSF C
Ingress Multiservice Switching Forum Controller
Ingress MSF SW
Ingress Multiservice Switching Forum ATM Switch
Ingress MGCP CA
Ingress Media Gateway Control Protocol Call Agent
November 3, 1998
MSF Confidential
26
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
B.1.3 Message Conventions
Protocol Message Conventions
Protocol
Example
Description
Abstract CA-to-CA
Protocol
Incoming Call
In italic, Times New Roman font.
PNNI
SETUP
In Modern (OEM) font, all capitalized, colored blue.
MGCP
CRCX
In bold, italic, Times New Roman font, all capitalized.
SS7/ISUP
IAM
In gray, Times New Roman font, all capitalized.
UNI
SETUP
In Times New Roman font, all capitalized.
VSI
Conn Cmt
Cmd
In Antique Olive font, colored red.
B.1.4 Parameter Conventions
SS7 Conventions
Abbreviations
Description
…
More parameters are used but not noted in the call flow for briefing.
Cd
Called Party Number
Cg
Calling Party Number
CIC-i
Circuit Identification Code at the Ingress GW
CIC-e
Circuit Identification Code at the Egress GW
EchoC
Echo Canceller
EchoC is the value in the IAM NOC “Nature of Connection Indicator”, which determines the
value in the “e” parameter in the CRCX message.
UNI IE Conventions
Abbreviations
Description
…
More IEs are used but not noted in the call flow for briefing.
Cd-nsap
Called Party Number information element that contains the NSAP address.
Cd-sub-addr
Called Party Sub-address is used to carry the secret token (encryption key).
Ci-vpi-vci
Connection Identifier information element
Cause
The Cause information element
November 3, 1998
MSF Confidential
27
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
PNNI IE Conventions
Abbreviations
Description
…
More IEs are used but not noted in the call flow for briefing.
Cd-nsap
See UNI IE Convention
Cd-sub-addr
See UNI IE Convention
Ci-vpi-vci
See UNI IE Convention
Cause
See UNI IE Convention
MGCP Conventions
Abbreviations
Description
…
More parameters are used but not noted in the call flow for briefing.
C
Call Id is used as a correlation Id for the whole duration of the call.
I-e
Connection Id for the connection at the egress side
I-i
Connection Id for the connection at the ingress side
L-e
Local Connection Option for the end point at the Egress GW
L-i
Local Connection Option for the end point at the Ingress GW
M
Connection Mode
O
Observed Event
R
Requested Event
S
Signal Request
SDP-e
Session Description Protocol description for the end point at the Egress GW
SDP-i
Session Description Protocol description for the end point at the Ingress GW
P
Connection Parameter
VSI Parameter Conventions
Abbreviations
Description
…
More parameters are used but not noted in the call flow for briefing.
vpi-vci-uni-nni
The End Point Identification
MBS
Maximum Burst Size (ATM Traffic Descriptor)
PCR
Peak Cell Rate (ATM Traffic Descriptor)
B.2
CALL FLOW DIAGRAMS
B.2.1 Scenario – UNI to UNI
This is a voice over ATM scenario employing UNI-to-UNI signaling between telephony gateways. The diagram
shows a scenario of a PSTN voice call request sent to the ATM network where:
November 3, 1998
MSF Confidential
28
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
1.
The MGCP CA controls the gateway(s) with the capability defined the “Media Gateway Control Protocol
(MGCP) Version 0.1 Draft, October 19, 98.
2.
The Ingress GW and the Egress GW are capable of performing UNI to UNI signaling.
3.
The scenario illustrates a trunking gateway to trunking gateway call setup and call clearing.
Notes:

In the call flow, only a portion of the Information Elements or parameters are shown for simplicity.

The Address Complete Message (ACM) is supported by SS7. However, it is not shown in this scenario for
simplicity.

COT is supported by MGCP. However, it is not included in this scenario.

The UNI SETUP message is initiated by the Egress GW for the following reasons:
1.
It allows routing to take place.
2.
It holds up the IAM until the ATM network establishes the voice path so that the caller can receive any call
treatment (i.e. announcement) from the Egress side.
November 3, 1998
MSF Confidential
29
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
B.2.2 Diagrams
UNI to UNI ( call setup )
Ingress
SS7
Ntwk Elem
Ingress
GW
Ingress
MGCP CA
Ingress
MSF C
Ingress
MSF SW
Egress
MSF SW
Egress
MSF C
Egress
MGCP CA
Egress
GW
Egress
SS7
Ntwk Elem
IAM (Cg, Cd, CIC-i, EchoC, ... )
CRCX span-i/timeslot-i@IngrGateway.net
(C, L-i, M, ... )
200 Ok ( I-i, SDP-i)
Incoming Call ( C, SDP-i, Cg, Cd )
CRCX span-e/timeslot-e@EgrGateway.net
(C, L-e, M, R, X, SDP-i, ... )
200 Ok ( I-e, SDP-e)
Progress ( C, SDP-e, ... )
SETUP
(Cd-nsap, Cd-sub-addr, ... )
Starting point of the
UNI to UNI signaling
Conn Cmt Cmd ( vpi-vci-uni-nni, PCR, MBS, ... )
Conn Cmt Rsp
Conn Cmt Cmd ( vpi-vci-uni-nni, PCR, MBS, ... )
Conn Cmt Rsp
SETUP
(Cd-nsap, Cd-sub-addr, ... )
CONNECT ( Ci-vpi-vci , ... )
CONNECT ( Ci-vpi-vci, ... )
CONNECT-ACK
CONNECT-ACK
NTFY span-i/timeslot-i@IngrGateway.net
( X, O, ... )
IAM (Cg, Cd, CIC-e, ...)
Progress ( C, SDP-e, ... )
ANM
MDCX span-i/timeslot-i@IngrGateway-i.net
(C, I-i, M, SDP-e, ...)
200 Ok
ANM
Two-Way-Path
November 3, 1998
MSF Confidential
30
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
UNI to UNI ( normal call clearing)
Ingress
SS7
Ntwk Elem
Ingress
GW
Ingress
MGCP CA
Ingress
MSF C
Ingress
MSF SW
Egress
MSF SW
Egress
MSF C
Egress
MGCP CA
Egress
GW
Egress
SS7
Ntwk Elem
Two-Way-Path
REL ( CC )
Release Indication ( C, CC )
RLC
REL ( CC )
RLC
DLCX span-i/timeslot-i@IngrGateway.net
( C, I-i )
200 Ok ( P -i )
Release Complete Indication ( C )
DLCX span-e/timeslot-e@EgrGateway.net
( C, I-e )
RELEASE ( Cause )
200 Ok( P-e )
RELEASE ( Cause )
RELEASE-COMPLETE
Conn Del Cmd
( vpi-vci-uni-nni, ... )
Conn Del Cmd
( vpi-vci-uni-nni, ... )
RELEASECOMPLETE
Conn Del Rsp
Conn Del Rsp
November 3, 1998
MSF Confidential
31
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
B.2.3 Diagram Descriptions
The following paragraphs list the protocol, message direction, brief description, and sample content for the principal
parameters for each message in the call flow diagrams of the previous section.
B.2.3.1 IAM
Protocol: SS7
Message Direction: From Ingress SS7 STP to Ingress MGCP CA.
Description: A voice call request sent to the MGCP CA from an SS7 network element.
Parameters:
Sample Content
Note
Cg = 972-498-1111
The calling party number
Cd = 973-829-2222
The called party number
CIC-i = 150
Ingress Circuit Identification Code
EchoC
Echo Cancel Indication (in SS7 Nature of Connection parameter)
B.2.3.2 CRCX (Ingress CA to Ingress GW)
Protocol: MGCP
Message Direction: From Ingress MGCP CA to Ingress GW
Description: Upon receiving the IAM message, the Ingress MGCP CA sends the CRCX message to set up a
connection.
Parameters:
Sample Content
Note
Span-i/timeslot-1@IngrGateway.net
The full endpoint name of the ingress circuit derived from the CIC-i
from the IAM message.
C : 11112AF
C is a unique call id that is generated (a random number) by the CA.
L-i : p:10,
The L-i describes the options of the end point at the Ingress GW, where
a:G.711

“p” specifies the packetization period in milliseconds,
e:on

“a” specifies the preferred type of compression algorithm.
k:method:key

“e” specifies the echo cancellor and the value is from the IAM
message “Nature of Connection Indicator (NOC)” IE.

“k” is a secret token which is assigned by the Ingress MGCP CA
used as a security check for the duration of this call. The secret
token should be unique. This mechanism is designed to prevent
fraudulent usage of the network.
M : recvonly
November 3, 1998
Setting a one way connection.
MSF Confidential
32
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
B.2.3.3 Ack-CRCX (200 Ok – Ingress GW to Ingress CA)
Protocol: MGCP
Message Direction: From Ingress GW to Ingress MGCP CA
Description: An acknowledgement to inform the CA that the connection is created successfully.
Parameters:
Sample Content
Note
I-i : FDE234C8
The connection id
SDP-i : v= 0.1,
SDP description of the end point at the
Ingress GW, where:
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe

“v” specifies the protocol version

“c” specifies connection information
m= audio VPI = 5/ VCI = 1002 ATM/AVP G.711u

“m” specifies network access media
a= connection_type:AAL1_SDT

“a” specifies the media attributes
k=See CRCX message

“k”, see Section B.2.3.2.
B.2.3.4 Incoming Call (CA to CA)
Defining the communication between the MGCP Call Agents is out of the scope of the MSF architecture. “Incoming
Call” is an abstract message used at this point in the call flow to facilitate the communication between MGCP Call
Agents.
Protocol: None (not currently a standardized protocol)
Message Direction: From Ingress MGCP CA to Egress MGCP CA
Description: After the Ingress CA identifies the Egress node, the incoming call request is sent to the Egress CA to
handle the egress portion of the call.
See the Parameter descriptions for CRCX and ack-CRCX.
B.2.3.5 CRCX (Egress SGCP CA to Egress GW)
Protocol: MGCP
Message Direction: From Egress MGCP CA to Egress GW
Description: The Egress CA sends the CRCX message to set up a connection. At the same time, the Egress GW is
asked to notify the Egress Call Agent when the UNI SETUP is completed.
November 3, 1998
MSF Confidential
33
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Parameters:
Sample Content
Note
Span-e/timeslot-e@EgrGateway.net
The full endpoint name of the Egress circuit as selected by the Egress CA.
This information will be used to generate the CIC-e when Egress GW
sending an IAM message to the Egress Ntwk Elem.
C: 11112AF
See section B.2.3.2 for description.
L-e: p:10,
The L-e describes the options of the end point at the Egress GW. For the
definition of “p” and “a”, see section B.2.3.2.
a:G.711
M: sendrecv
Setting a two-way connection.
R: sc (setup complete)
Request the Egress GW to notify the CA when the UNI SETUP between
the Ingress GW and Egress GW is completed. If the UNI setup failed, the
GW should send the DLCX to the Egress CA.
Note: This is not yet defined in MGCP
V0.1. However, it is necessary and
therefore created for this scenario.
X : F12345A
CA generates the request id for correlate the notification from the gateway
later.
SDP-i:
See SDP-i in section B.2.3.3.
B.2.3.6 Ack-CRCX (200 Ok -- Egress GW to Egress CA)
Protocol: MGCP
Message Direction: From Egress GW to Egress MGCP CA
Description: An acknowledgement to inform the CA that the connection is created successfully.
Parameters:
Sample Content
Note
I-e : ADE234C8
The connection id
SDP-e : v= 0.1,
SDP description of the end point at the
Ingress GW. For the definition of the subparameters, see section B.2.3.3.
c= ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe
m= audio VPI = 5/ VCI = 1004 ATM/AVP G.711u
a= connection_type:AAL1_SDT
B.2.3.7 Progress (CA to CA)
Protocol: None
Message Direction: From Egress MGCP CA to Ingress MGCP CA
Description: The “Progress” is an abstract message used to inform the Ingress CA that the endpoint at the Egress
GW is successfully setup.
November 3, 1998
MSF Confidential
34
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Parameters:
Sample Content
Note
C: 11112AF
See the description in Section B.2.3.2
SDP-e :
See the description in Section B.2.3.6.
B.2.3.8 SETUP
Protocol: ATMF UNI 4.0 and ATMF PNNI 1.0
Message Direction:
From Egress GW to Egress MSF C (UNI)
From Egress MSF C to Ingress MSF C (PNNI)
From Ingress MSF C to Ingress GW (UNI)
Description: The messages are sent for initiating the call/connection establishment.
Information Elements:
Sample Content
Note
Cd-nsap =
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe
Called Party Number information element that
contains the NSAP address.
Cd-sub-addr = k
Cd-sub-addr is used to carry the value in “k”.
B.2.3.9 Conn Cmt Cmd
Protocol: VSI
Message Direction:
From Egress MSF C to Egress MSF SW
From Ingress MSF C to Ingress MSF SW
Description: The MSF Controllers are setting up the intra ATM switch connections.
Parameters:
Sample Content
Note
vpi-vci-uni-nni
The vpi-vci-uni-nni is the endpoint identification.
PCR
The value is from the information given in the SETUP message.
MBS
The value is from the information given in the SETUP message.
B.2.3.10 CONNECT
Protocol: ATMF UNI 4.0, ITU PNNI
Message Direction:
From Ingress MSF GW to Ingress MSF C (UNI),
From Ingress MSF C to Egress MSF C (PNNI),
From Egress MSF C to Egress GW (UNI),
Description: The CONNECT messages are sent to indicate the call/connection acceptances.
Information Elements:
Sample Content
November 3, 1998
Note
MSF Confidential
35
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
Ci-vpi-vci
Connection Identification information element that contains the VPI/VCI.
Note: As an alternative, the IE could be used in the UNI SETUP message as defined in
Q2931.
B.2.3.11 NTFY
Protocol: MGCP
Message Direction: From Egress GW to Egress MGCP CA
Description: A notification informs the CA about the completion of the virtual path setup.
Parameters:
Sample Content
Note
X : F12345A
X is the request id that CA generated in the CRCX (Egress MGCP CA to Egress
GW) to correlate the notification from the gateway.
O : sc
The observed event : the UNI “setup complete”.
B.2.3.
IAM
Protocol: SS7
Message Direction: From Egress MGCP CA to End System.
Description: The Initial Address Message is sent to the Egress SS7 Ntwk Elem.
Information Elements:
Sample Content
Note
Cg = 972-498-1111
The calling party number
Cd = 973-829-2222
The called party number
CIC-e
Circuit Identification Code at the Egress Gateway. The value is derived from the SPD-e.
B.2.3.12 ANM (Egress Ntwk Elem to Egress MGCP CA)
Protocol: SS7
Message Direction: From Egress Ntwk Elem to Egress MGCP CA
Description: The Egress MGCP CA is informed that the Egress SS7 Ntwk Elem received “answer” event.
B.2.3.13 Progress-Answer-Indication (CA to CA)
Protocol: None
Message Direction: From Egress MGCP CA to Ingress MGCP CA
Description: An abstract CA to CA message to inform the Ingress CA that the “answer” has occurred.
November 3, 1998
MSF Confidential
36
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
B.2.3.14 MDCX
Protocol: MGCP
Message Direction: From Ingress MGCP CA to Ingress GW.
Description: Modify the one-way connection to a two-way connection.
Parameter:
Sample Content
Note
C : 11112AF
See the description in Section B.2.3.2.
I-i : FDE234C8
The connection id.
M : sendrecv
Set a two-way connection.
SDP-e
See “SDP-e” in Section B.2.3.6.
B.2.3.15 Ack-MDCX (200 Ok)
Protocol: MGCP
Message Direction: From Ingress GW to Ingress MGCP CA.
Description: Acknowledge the MGCP CA that the connection modification is successful.
B.2.3.16 ANM (Ingress MGCP CA to Ingress SS7 Ntwk Elem)
Protocol: SS7
Message Direction: From Ingress MGCP CA to Ingress SS7 Ntwk Elem.
Description: Acknowledge the Ingress SS7 Ntwk Elem that the “answer” has occurred.
B.2.4 Call Clearing
The following text describes the normal call clearing procedures shown in the call flow:
The normal call clearing request (SS7 REL message) is sent to the Ingress CA to clear the call. The Cause Code
(CC) indicates that the call clearing request is a normal call clearing (not due to an error condition).
1.
Upon receiving the call clearing request, the Ingress CA sends the abstract CA to CA message to inform the
Egress CA to handle call clearing at the egress side. Simultaneously, the Ingress CA sends an RLC (SS7 Release Complete message) to the Ingress SS7 Ntwk Elem.
At the same time, the CA sends the DLCX (MGCP DeleteConnection) to the Ingress GW to clear the established connection at the ingress side.
To acknowledge the successful deletion of the connection, the Ingress GW sends a “200 Ok” with the Connection-parameter ( P-i ) that describes the status of the connection (i.e. number of packets sent, number of
packets received, number of packets lost, etc.). These connection status information can be used for traffic
performance statistic study or billing.
2.
On the egress side, upon receiving the abstract message “Release-Indication,” the Egress MGCP CA sends
REL (SS7 Release message) to Egress SS7 Ntwk Elem to initiate the normal call clearing.
Upon receiving the RLC (SS7 Release Complete message), the Egress MGCP CA starts to delete the connection at the egress side. The Egress CA sends the abstract message “Release Complete Indication” to inform the Ingress CA that the egress side connection deletion is underway.
November 3, 1998
MSF Confidential
37
Multiservice Switching Forum (MSF) System Architecture Implementation Agreement MSF 1.0
3.
At some point after receiving the MGCP DLCX message, the Egress GW initiates UNI call clearing. In this
scenario, the following assumptions have been made to reduce glare during call clearing in the ATM network:

The UNI RELEASE is initiated by the egress GW (i.e., the one that initiates the UNI SETUP). In this
call flow scenario, the Egress GW has initiated the UNI SETUP. Therefore, the Egress GW initiates
the UNI RELEASE.

The ingress GW (i.e., the gateway that received the UNI SETUP during call establishment phase) will
initiate the UNI RELEASE after a pre-set time period in the event that the initiating GW fails or delays to do so.
Upon receiving the UNI RELEASE, the Egress MSF C and Ingress MSF C handle the call clearing in the ATM
network as shown in the call flow.
November 3, 1998
MSF Confidential
38