Introduction
In recent years, there has been widespread global interest in the Next-Generation Network (NGN) model as a framework for the evolution of packet-based networks. Extensive standardization efforts lead by the ITU-T and regional standards development organizations such as ETSI and ATIS have generated a broad industry consensus on the basic NGN architecture model and services, as well as other related domains of interest. Much of this activity has been documented by the ITU-T NGN Focus Group in its Technical Reports, and an overview of this work has been described in [1].
Figure 1. The ITU-T NGN Framework Functional Architecture Model
The general NGN architecture is typically described in terms of "functional blocks" or components that are used in combination to enable service providers to support a range of multimedia services. A high-level, generic view of this approach is shown in Figure 1, based on the Technical Report developed by the ITU-T NGN Focus Group (FGNGN) [2]. More detailed representations of the NGN have also been developed by the ITU-T and other bodies such as ETSI TISPAN and ATIS, etc. in order to specify the functions and interfaces for standardization.
The NGN functional model provides for a clear distinction between functions that are "transport" related, and those that relate to "service" generation and coordination. NGN telecommunications and broadcast services include many currently provided by either wireless, fixed network and cable networks, as well as new envisaged multimedia services. The transport functions are intended to include all those functions responsible for the forwarding and routing of IP data packets, including those needed to support the required QoS capabilities for any given service.
Although the NGN functional blocks have been described in detail, their relationship to the actual protocols used to support these functions have, in general, not been described so far. This is mainly because it is generally assumed that NGNs will be based on existing transport-, control-, and management-related technologies in use already, or in development by the SDOs such as the IETF, so that those protocols will simply be referenced as part of the overall NGN framework. Although this is a valid assumption, it is also important that the relationship of these protocols to the overall NGN architecture, as well as to each other, is clearly defined to avoid ambiguity and promote interoperability.
This paper describes a generic protocol "reference model" for the NGN functional architecture that clarifies the relationship of the proposed protocols to the NGN functional blocks. It also discusses the relationship between the control and management capabilities, and seeks to clarify the distinctions between them, where appropriate. It is intended that such an NGN Protocol Reference Model (PRM) can be used in conjunction with the NGN Framework Architecture (FRA) model to get a better understanding of the NGN, analogous to the way protocol reference models were an integral part of the description of existing ISDN-/BISN- and cable-based networks.
Cisco IP Next-Generation Network Architecture
Before entering into a more detailed description of the protocol architectures that comprise the standardized view of the NGN outline described previously, it is useful to summarize how the NGN functional model of Figure 1 relates to the Cisco® IP Next-Generation Network (IP NGN) architecture adopted by the company as the basis of its vision for supporting global NGN Service Providers. Cisco has long recognized the importance of the NGN vision for its service provider business and is committed to supporting that vision in its product portfolio and systems. A high-level overview of the Cisco IP NGN architecture and its correspondence to the ITU-T NGN functional model is shown in Figure 2. This IP NGN model can be directly compared to the ITU-T NGN model in Figure 1, showing the close similarities as well as some differences.
The functions in the circles, which correspond to the standardized nomenclature from Figure 1, clearly indicate the close relationship of the standard (ITU-T) NGN functional model to the Cisco IP NGN framework. Given Cisco's long-term commitment to supporting open, interoperable interfaces and standards, such a close correspondence between these models is hardly surprising, and in fact, is a strategic advantage in the service provider sector.
Figure 2. Cisco IP NGN Architecture and relationship to ITU-T NGN model
In the Cisco IP NGN architecture, the Network Layer corresponds broadly to the Transport Stratum of the NGN functional model, whereas the Service and Application Layer correspondences are straightforward. Allowing for the minor differences in terminology, the corresponding NGN functions from Figure 1 can be mapped to their counterparts in Figure 2 as shown previously. However, not all NGN functional blocks can have direct correspondences in the IP NGN architecture, although this fact does not imply that these functions cannot be supported within the Cisco IP NGN architecture. Thus, some of the unmapped functions listed previously can be incorporated either within the IP NGN Service or Network Layers, for example. Because the functional blocks depicted here represent logical entities, partitioning of these entities within any given product is largely an implementation decision.
It is evident from Figure 2 that the Cisco IP NGN architecture includes a substantial range of capabilities in order to support the range of applications and services service providers need in a competitive environment. Some specific networking applications, such as the provision of virtual private networks (VPNs) at either Layer 2 or 3, are also shown in the IP NGN architecture. Other generic network capabilities, such as functions to enable quality of service (QoS) attributes, can be grouped as IP NGN enablers, because they can be distributed over more than one layer of the model.
Bearing in mind this close correspondence between Cisco IP NGN architecture and the standardized NGN functional model, we now describe in further detail the functions in the various layers and the relationship to the planes in the NGN model.
Control and Management Planes in the NGN
Telecommunications networks, including many packet-based networks, typically incorporate the concept of a clear separation between the functions in the "control or signaling" planes and those in the "management or OAM" planes. This concept is an integral part of the ISDN/PSTN, as well as the traditional ATM-based B-ISDN models, and has proved to have advantages in terms of specification and interoperability of interfaces and service capabilities.
Although the NGN framework architecture does in principle embody the concepts of separate control and management planes, in practice these categories of functions are somewhat blurred in the actual functional architecture. This blurring may be partially due to the assumption that the NGN is based on an IP networking model, which traditionally is not overly concerned with fine distinctions between control- and management-related functions or messages, because virtually everything in that model is viewed as an "application" carried over IP transport.
Although such an approach can be workable in the case of an "unmanaged" or unregulated Internet, it would be difficult to extend it to the NGN concept, which by definition will be required to support bounded QoS for certain services, as well as enforceable service-level agreements (SLAs). Consequently, it may be advantageous for the NGN framework to more clearly specify the separate control- and network management-related functions and interfaces, as well as the relationships between these, so that network operators can develop the appropriate processes and operational structures to support NGN services.
By analogy with conventional networks, management functions are typically related to support the following capabilities:
1. Fault Management (including alarm surveillance and survivability)
2. Configuration Management (including network dimensioning/ traffic engineering)
3. Accounting Management (including billing records)
4. Performance Management (including in-band and out-of-band testing/monitoring)
5. Security Management (typically at all levels of network operations)
These network management capabilities constitute an enormous range of functions and related technologies, and can be combined in different ways to support any given SLA. In the NGN framework, many these capabilities are expected to be handled by the so-called "AAA" (authentication, authorization, and accounting) interfaces and associated databases. However, the relationship of this approach to overall network management capabilities will need to be clearly defined. Work in this area has begun in numerous forums, but clearly much needs to be done to ensure support of all the required capabilities.
An important aspect of network management that is often overlooked is the relationship between the overall management interfaces and what is sometimes called "layer operations and maintenance (OAM)," which is needed for capabilities such as alarm surveillance and performance monitoring. Layer (also sometimes called in-band) OAM functions are responsible for fault and performance monitoring within any given layer of the network protocol architecture, and are able to communicate OAM event information up to the network management system via specified internal interfaces. Examples of typical layer OAM functions are the alarm surveillance (AIS/RDI) protocols in SDH- and ATM-based networks.
The layer OAM functions in any given layer of the NGN protocol architecture should be able to communicate relevant fault or performance monitoring information to the network element management system. This system in turn filters the information for the network management system (or OSS) via the management interfaces, which can be either standardized or proprietary. As can be seen, there is consequently a close relationship between the layer OAM capabilities and the overall network management system, and this relationship needs to be reflected in any protocol reference model for the NGN. This aspect is further discussed in the section dealing with network management protocols.
Control-plane capabilities typically comprise the myriad functions related to signaling and routing of calls and connections (or sessions) within the overall network. Signaling and routing protocols and the associated interfaces are part of the control plane, and although they can interact closely with the management plane, it is important to understand that they constitute a separate and distinct category of protocols to the management or OAM protocols. In the NGN Framework architecture, such a separation needs to be clarified in order to facilitate the development of the interoperable protocols and interfaces. This is clearly the case for existing carrier-grade networks, and there appears to be no reason why the concept should not be equally of value for the NGN.
It is important to clarify the close relationship between the control-plane capabilities and typical telecommunications services. In essence, most services are enabled by the underlying signaling protocols, which are used to carry the information on which a given service is supported. As is well known, conventional SS7-/AIN-based networks offer a wide range of services enabled by the "common-channel" (SS7) signaling protocols and the AIN architecture used to generate and coordinate these services. In the NGN architecture model, an analogous relationship exists between the control functions and the messaging used to convey the service-related information between NGN network elements.
In the NGN control plane, signaling messages for either session-oriented (that is, SIP-based) or non-session-based protocols can be used to convey the required information elements that enable the NGN Service Stratum functions to generate and coordinate the requested service. This implies that the processing of the signaling information elements is closely associated with the service functions within the Service Stratum. The associated applications functions can use the information to provide the particular services requested, as envisaged in the NGN functional model. This distinction between the service applications and the underlying control (signaling) capabilities needs to be kept in mind when developing a suitable protocol reference model for the NGN framework.
Connectionless and Connection-Oriented Transfer Modes
The NGN framework allows for the use of either connectionless (CL) or connection-oriented (CO) packet-transfer technologies, as well as combinations of these technologies if required. However, it is generally accepted that a common element in either case is the use of the Internetworking Protocol (IP) stack for carriage of connectionless packets in the NGN. In developing a generic protocol reference model for the NGN framework, it is necessary to include all these aspects in the protocol architecture. Although this inclusion complicates the representation of a generic model somewhat, it demonstrates more clearly the relationships between these complementary technologies.
Although the NGN framework architecture developed by the ITU-T NGN Focus Group and others so far does not explicitly show the protocol layer architectures required by the various NGN components or planes, it is clear that for any of the transfer, control, or management planes, a logically layered protocol architecture is inevitable, as for all packet networks. Depending on what specific combination of CO or CL packet network is envisaged, the protocol layering may be somewhat different, but in any case the NGN Transport Stratum would require the typical layering of protocols, as for conventional IP-based networks. The NGN implies the need for additional functions related to support of QoS, security, survivability, etc. These capabilities build on the underlying packet transport in most cases, but may also introduce additional layer functions to support some aspects of these capabilities.
Access and Core Technologies
The NGN framework architecture recognizes the differences between the technologies that can be employed in the "Access" part of the network from those used in the "Core" part of the NGN. Consequently, this distinction should be reflected in the NGN protocol reference model, which accounts for the various technologies that can be used in the access, such as Cable, Wireless, or Wireline (DSL, Ethernet, Optical, etc.) technologies. The protocols for these technologies, specifically for transport, may differ significantly. In order to account for such differences, a generalized protocol model for the NGN can be represented as shown in Figure 3, which also incorporates the separation between the transport-, control-, and management-plane functions outlined previously.
Figure 3. General Protocol Reference Model for the NGN
The NGN core network architecture assumes the use of IP-based transport, although there is widespread support for the use of MPLS as well, in conjunction with IP, for enhanced traffic engineering and QoS control. The core network protocol architecture can, therefore, focus on the IP/MPLS-based technology, although the use of basic IP is not precluded by this representation. It should be noted that the assumption here is that use of MPLS implies essentially a connection-oriented transfer mode, because some form of label distribution protocol will be required for setting up the label switched paths (LSPs).
The NGN Protocol Reference Model
The generalized protocol model outlined previously can be further developed to include the detailed protocol architectures for typically used CL or CO technologies, for both core and access networks, resulting in the protocol reference model for the NGN framework as shown in Figure 4.
Figure 4. Detailed Protocol Reference Model for the NGN Framework
Although the model in Figure 4 may appear somewhat complex at first glance, comparison with the overview ITU-T NGN framework of Figure 1, and decomposition into the component CL and CO access and core parts, can be used to clarify the relationship of the individual protocols to the NGN architecture. The descriptions in subsequent sections of this paper relate to the specific protocol stacks and the control, management, and transfer planes corresponding to this model.
A main feature of the NGN Protocol Reference Model represented in the figure is the use of IP as the common packet mode transfer protocol in virtually all technology configurations. It is generally recognized that the IP suite of protocols will form the "common element" in the NGN framework. It is primarily for this reason that the model is often referred to as the "IP NGN Framework." The use of IP as the common packet transfer mode has far-reaching implications on virtually all aspects of the NGN functional architecture, because it determines how the basic attributes of the NGN, such as QoS, security, survivability, etc., are implemented.
It will also be recognized that the IP packets can be transported over a variety of "Layer 2" packet mode protocols, such as Ethernet, PPP, Frame Relay, ATM, etc., as well as several possible underlying "Layer 1" technologies, including SDH, OTN/GFP, Ethernet, PON, Cable, DSL, Wireless, etc. All these related protocols (and their associated control and management capabilities) form an integral and important part of the overall NGN framework architecture. Although we typically focus on the IP-related aspects, the capabilities and interactions with the other underlying protocols should not be underestimated when describing the NGN framework.
NGN Transport Protocols in the Access and Core
In the subsequent sections, we briefly describe the main characteristics of the transport protocol candidates for the core and access parts of the NGN framework. As pointed out earlier, combinations of compatible transport protocols are not precluded in any specific NGN scenario, provided the required NGN services can be supported.
Core Transport Protocol Architecture
For the case of connectionless packet switched core networks, the protocol architecture is essentially similar to traditional Internet architectures based on "Packet-over-SONET/SDH" (PoS) solutions, or IP over PDH-based transmission systems. However, it is generally accepted that an MPLS sublayer will be used for the transport of the IP packet streams in order to take advantage of the additional QoS and traffic engineering capabilities enabled by MPLS technology.
The core transmission networks use optical fiber-based SDH/SONET, PDH (DS-3), or the emerging Gigabit Ethernet (GE) technologies to support ultra-high (multigigabit) bandwidth transport. These systems provide the very high performance and survivability attributes that constitute the important hallmarks of carrier-grade NGN transport. Optical interfaces capable of line rates of 10 Gbits/sec and more are now commonplace in SDH core networks, and Gigabit Ethernet (metro) transport systems are increasingly playing a role in network evolution toward the NGN.
Because MPLS lacks some conventional (Layer 2) functions, such as frame delineation and error detection, it is necessary to provide these capabilities, typically by interposing a protocol such as Point-to-Point Protocol (PPP) between the transmission (for example, SDH) system and the MPLS (sub) layer. This interposition is shown in Figure 4. However, it is also possible to use other conventional Layer 2 protocols for this purpose, such as the ITU-T Generic Framing Protocol (GFP). The core network provides conventional routing capabilities for the IP-based services, so that the layers above the IP layer are primarily dependent on the specific services being transported, typically voice, video, or data applications encapsulated in UDP, TCP, or RTP packets. In this respect, the NGN PRM is very similar to existing Internet architectures.
For the case of connection-oriented packet-switched core networks, the IP packets are typically transported by an ATM (or Frame Relay) layer, as shown in Figure 4. Again, the Physical Media Dependant (PMD) layer is typically optical fiber-based, using SDH/SONET or Ethernet transmission protocols, as for the CL case previously described. The ATM/AAL protocols provide all the required functions for the carriage of the IP packets, including the enhanced QoS and OAM capabilities for the support of multimedia services with carrier-grade availability and survivability. As for the previous case, the protocols above the IP layer are somewhat application-dependant, but essentially no different from the CL packet-switched networks.
It should also be noted that in the case of CO networks, although it is typically assumed that IP will be part of the protocol architecture, it is also possible that the ATM transport can be used to support envisaged NGN services, without the need of the intervening IP layer. This possibility is indicated in Figure 4 by using the notation (?) in the CO protocol stack. Because the ATM/AAL protocols were designed to support a range of multimedia services, including the transport and switching of IP packets for data services, the NGN framework does not preclude the use of ATM only, or mixed IP/ATM protocol architectures, as signified by this notation.
Access Transport Protocol Architectures
As can be expected, the access part of the NGN encompasses the widest range of technologies, including xDSL, Cable, Wireless, or Metro Ethernet. Consequently, it is not surprising that the protocol architectures in the Access networks exhibit significant differences, depending on the specific access transport technology in question. In addition to these main differences resulting from the type of access technology, there are also differences resulting from the use of either CL or CO packet-switched approaches, where applicable. The following sections outline the main attributes of the access technologies shown in Figure 4, highlighting differences resulting from CL or CO options where appropriate.
Cable Networks
Broadband cable access networks are based on the DOCSIS® family, coupled with the PacketCable™ architecture specifications (also issued as the IPCablecom standards by the ITU-T) for the provision of multimedia services over cable networks [3]. The DOCSIS family of specifications defines a Radio Frequency Interface (RFI) capable of upstream data-transfer rates up to 30 Mbits/sec over shared cable media using a cable-specific Media Access Control (MAC) protocol. The DOCSIS and PacketCable protocols also provide for dynamic QoS (DQoS) for the support of multimedia NGN services.
In addition to the RFI, the DOCSIS protocol-based architecture includes a MAC layer for the shared media cable network, operating between the cable modem (CM) and the cable modem termination system (CMTS) functions located in the cable operator network. The evolving IPCablecom/PacketCable architecture, including the DOCSIS protocols, are rapidly converging within the overall NGN framework in terms of required functions, led by the need for common control protocols for the delivery of NGN services, as described further in the section on control protocols.
Essentially, from the perspective of transport protocol architecture, the main difference between cable and other access technologies are in the (Layer 1) physical media dependent (PMD) and transmission functions, such as the RF modulation and encoding schemes. It should be noted that the main difference between the CL and CO packet-switched NGN categories, from the perspective of the cable access network, is the option of using ATM in the (DOCSIS) cable protocol architecture for the CO case.
DSL Access
Broadband access based on xDSL technologies, such as existing asymmetrical DSL (ADSL) or the evolving very-high-bit-rate DSL (VDSL), etc., are popular means for Internet access, and they constitute a major component of the NGN framework. The DSL technologies use sophisticated modulation and encoding protocols to provide broadband (~ Mbits/sec and above) data rates over copper pairs, although the achievable bit rates to given users are highly distance-sensitive [4]. ADSL protocols are the most widely deployed, and they use conventional ATM protocols to support QoS capabilities. It is also proposed to evolve the DSL transport protocols to directly carry IP packets (without using intervening ATM encapsulation), and such an evolution can be accelerated by the trend to push IP transport toward the network edge.
As for the case of cable access technologies, the main protocol differences appear in the physical layer, where the xDSL PMD layer requires modulation, encoding, and transmission schemes developed specifically for efficient use of bandwidth over existing copper pairs. From the xDSL access transport protocol architecture point of view, there is essentially no difference between the CO or CL categories of the NGN framework based on current specifications. However, this situation may change if the use of IP-only xDSL systems is introduced, removing the need for interposing an ATM layer in the xDSL protocol architecture.
Ethernet-Based Access
The increasing use of Gigabit Ethernet (GigE or GE) and Metro Ethernet transport networks represents a significant dynamic in the evolution toward the NGN framework. The use of Ethernet-based protocols in the WAN would appear as a natural extension to its conventional use in the LAN, enabling the encapsulation of the IP packets directly into Ethernet frames for transfer to the core network. Access aggregation based on Ethernet protocols is viewed as a primary enabler for services such as VPNs and video distribution as part of future set of NGN services.
Wireless Access
Wireless access (including cellular mobile) networks constitute an important and varied part of the overall NGN framework. Cellular mobile wireless protocols display significant regional differences, depending on the type of systems deployed (TDMA/GSM or CDMA), as well as whether circuit-switched (CS) or packet-switched (PS) technology is used in the Radio Access Networks (RAN). However, for the purposes of the NGN PRM, we indicate the basic protocol layering for the packet-switched wireless network, with the air interface as part of the RFI PMD, and use of either CDMA- or TDMA-based encoding systems.
For many existing PS RANs, ATM /AAL Type 2 or Frame Relay protocols are in widespread use for transport between base stations and mobile switching centers, so that these can be grouped in the CO category of the NGN framework. However, there is a trend to evolve RANs toward an all-IP transport model, so that this possibility should also be accounted for in the general PRM, as shown in Figure 4. In such cases, additional Layer 2 protocols, such as PPP, will be required to provide critical functions such as framing and error detection. As can be seen from Figure 4, this aspect constitutes the main point of difference between CL and CO categories of the NGN PRM for the case of RANs.
Because wireless mobile technologies are evolving rapidly to support higher bandwidths and multimedia capabilities, it is clear that additional functions will be incorporated into the appropriate layers of the wireless protocol stack. From the access transport perspective, these capabilities will affect the lower layers of the wireless protocol architecture, such as the RFI or the CDMA/TDMA protocols. However, as described in the following section, there are significant evolutionary trends in terms of the control and services planes for wireless networks, and these are often seen as the main focus of the evolution toward the NGN. An example of this evolution is the current drive to evolve toward the ETSI /3GPP IP Multimedia Subsystem (IMS) control architecture, which is expected to generate new services based on the flexibility provided by IP-based applications.
The Services/Control Layers
The NGN model defines a clear distinction between the Transport Stratum (the term Stratum is intended to signify a set of one or more layers, as conventionally described in the ISO layer representation) and the Services Stratum. The service stratum includes the control functions as well as the applications layer(s). As noted earlier, it is important to clarify the relationship between services and control, or signaling, functions. The control/signaling messages are intended to carry the signaling- and service-related information between the users and networks, as well as between the network elements. The control functions process this information in order to generate the required services in conjunction with the specific application required.
The application "layer" is considered a part of the NGN Service Stratum, although, in essence, the various "applications" can be viewed as distinct entities that create specific NGN services, such as VoIP, VoD, IM, and so on. The terms applications and services are often used interchangeably in the NGN context, but typically applications are the collection of (typically software) functions that generate the service in question, such as IM, for example.
The control functions related to signaling form part of the control plane, although this fact is not explicitly shown in Figure 4 for the sake of simplicity. The NGN model allows for numerous potential signaling/control protocols, depending upon the transfer mode and the interfaces involved. For the case of CO transport layers, conventional signaling and routing protocols such as UNI (derived from ITU-T Recommendation Q. 2931), PNNI, Bearer Independent Call Control (BICC), and so on can be used, depending on the interface in question. It should be noted that many of these well-established control-plane protocol architectures relate to the transport layers of the NGN PRM.
The use of the conventional routing protocols, such as OSPF, BGP, IS-IS, etc., is implied as a result of the presence of the common IP layer in the PRM. In addition, other IP layer protocols, such as RSVP, can also be used as required, for resource reservation and/or traffic engineering purposes, within the NGN control-plane framework.
NGN Control-Plane Protocols
As indicated in Figure 3, the NGN control-plane protocols required depend on whether the CL or CO categories of the NGN are to be implemented. The control plane includes both routing and signaling protocols, and the interactions between them.
For CL NGNs, the conventional IP routing protocols are specified for use, in much the same way as for the existing public Internet. These protocols include one or more of the following:
1. Open Shortest Path First (OSPF) routing
2. Intermediate System-to-Intermediate System (IS-IS) routing (ISO)
3. Border Gateway Protocol (BGP) routing
The signaling protocols that can be used include:
1. Resource Reservation Protocol (RSVP), or RSVP-TE
2. Session Initiation Protocol (SIP)
3. ITU-T Recommendation H.323
4. Hypertext Transfer Protocol (HTTP)
5. Label Distribution Protocol (LDP) for MPLS
In addition, the signaling protocols required for any specific Layer 2 protocol can also be used for the transport of IP packets.
For the case of CO NGN category, the routing and signaling protocols depend on the specific Layer 2 transfer technologies in place. For the case of ATM networks, the most commonly used routing (and signaling) protocol is PNNI. Although use of the B-ISUP-based routing (and signaling) specifications is not precluded, these specifications are not in typical deployments.
The signaling protocols for CO NGNs include:
1. UNI/ Q.2931
2. PNNI
Although Frame Relay-based networks can have their own associated signaling protocols, in practice, most FR networks are typically statically provisioned. Hence, the signaling protocols for FR-based networks are not shown.
Role of Session Initiation Protocol (SIP) and the IMS
The use of the Session Initiation Protocol (SIP) has received substantial attention as a component of the NGN, particularly because it has been selected as the basis of the IP Multimedia Subsystem (IMS) specifications developed by 3GPP, and adopted as an integral part of the overall NGN model. The basic SIP specification developed by the IETF [5] has been enhanced by the ongoing activity in the 3GPP and ETSI TISPAN groups in order to support the wide range of applications and services required by service providers as part of the IMS initiative. Although initially targeted toward the wireless (3G) mobile networks, the IMS framework is expected to be applicable to other technologies, and is viewed as a critical component of convergence in the control plane.
The IMS component of the NGN uses SIP as the basic signaling protocol for the control of session-oriented services such as VoIP, PTT, or IM, etc. The SIP messages (termed "Methods" in the IETF terminology) transport the services-related information encoded into the Session Description Protocol (SDP) in a manner analogous to the way conventional e-mail messages carry attachments, thereby enabling flexible support of a wide range of (multimedia) services.
The IMS control model developed by 3GPP/ETSI is analogous in some ways to the existing Advanced Intelligent Network (AIN) model used in telephony in that it defines an architecture that enables service providers to generate, control, and charge for services delivered to customers, on either mobile or fixed networks [6]. The IMS architecture uses SIP/SDP as well as other protocols to support these capabilities. Most of the required protocols have been defined by the IETF, such as RADIUS/DIAMETER or COPS. Consequently, the IMS-specified suite of control protocols can be viewed as part of the overall NGN control plane. However, it should be noted that some of the functions required for this purpose can also be regarded as management plane-related, because they support capabilities such as database query for billing or security, or policy-related messaging for access control.
In the NGN framework, the policy defined by the service providers for service delivery and resources management can be supported by a range of protocols, including DIAMETER, Common Open Policy Service (COPS), or Simple Object Access Protocol (SOAP). However, for the case of the IMS component, it is proposed that a restricted set of protocols including DIAMETER be used in order to promote interoperability. The NGN framework architecture incorporates a component termed the Resource and Admission Control Function (RACF) as part of the Transport Layer, which comprises the Policy Decision Functions (PDF) and the Policy Enforcement Points (PEP), which can be used for resource management in support of QoS for any given service set.
Consequently, the policy control protocols operate as part of the control plane in the Transport Stratum of the NGN model, but are in turn controlled by the Service Stratum control capabilities in support of any given service provided by the service provider.
For non-session-oriented services, a range of existing protocols widely used in the public Internet can also be used in the NGN framework. These protocols include HTTP, POP3, etc. for support of services such as Web access, e-mail, IM and Peer-to-Peer (P2P), and so on. Although the use of any of the common IP-based control protocols is not precluded in the general NGN framework, to date, the focus has largely been on specifying the session-oriented capabilities, specifically as related to the IMS model, which is often viewed as the first step in implementing an NGN. Nonetheless, support of such services (and their associated protocols) by the NGN and their interworking with the IMS-related services will be a requirement and, hence, needs to be factored in the NGN model.
Application (Layer) Protocols
The NGN is envisaged as enabling the support of a wide range of services or applications, as depicted in Figure 3, and these terms are used somewhat interchangeably in this context. The application layer is viewed as part of the NGN Services Stratum, and the protocols that form part of the application layer include those that generate services such as VoIP, IM, PTT, and a host of others envisaged by combining data, voice, and video signals into various types of multimedia services.
Such applications can be supported by the underlying signaling/control protocols for exchange of information between functional entities, but are distinct from the control functions in that they generate the service in question. At this stage, the NGN model does not restrict the applications that can be supported, provided they are consistent with the main attributes implied by the NGN.
Management-Plane Protocols
The NGN model includes the concept of a distinct management plane comprising all network management capabilities, including the conventional fault, configuration, accounting, performance, and security (FCAPS)-related functions as noted previously. It is widely accepted that these functions are necessary for supporting service-level agreements, as well as for enabling the operational aspects for network reliability and survivability.
The NGN architecture model allows for the use of conventional telecommunications network management protocols, such as Simple Network Management Protocol (SNMP) or Common Management Information Protocol (CMIP), for the transfer of management-related information between network elements and the Operations Support Systems (OSS). Various versions of both SNMP and CMIP are already in widespread use for managing existing networks, and it is likely that these commonly used protocols will simply be enhanced for use by the NGN by adding to the Management Information Base (MIB) specified for any given interface. SNMP has been developed by the IETF for IP-based network management, and CMIP was developed by the ITU-T as part of the Telecommunications Management Network (TMN) framework.
In addition, because the NGN model encompasses a common IP layer, other protocols specifically developed for the management of IP-based networks can also be used. Many of these protocols have been designed to support the "authentication, authorization, and accounting" management model developed by the IETF and intended for IP-based networks. Typically, these protocols, such as RADIUS, or its enhancement DIAMETER, can be directly adapted for use with the NGN framework.
In addition, other IP management protocols such as SOAP or LDAP can also be used for database query/response purposes in much the same way. It is evident that most of these protocols assume a (management or database) server-based architecture, typically with distributed OSSs over the network.
In conjunction with this set of protocols intended for MIB exchange across the OSS-to-NE interfaces, the NGN management plane also needs to include any "layer"-specificOAM functions, such as can be used for fault or performance monitoring/management. Examples of these functions include the widely used "alarm surveillance" and loopback (also called "ping") capabilities available in carrier-grade transport technologies such as SDH and ATM. The critical attribute of such OAM protocols is that they are intended for the (fault, performance, and survivability) management of the particular layer in which the protocol is defined, and not layers above or below it.
The layer management protocols (for alarm surveillance and performance monitoring) provide the relevant information to the network element management system, which in turn can pass the relevant (filtered) information required by the OSS via the SNMP (or CMIP) interface (also known as the OSS-to-NE interface). Alternatively, other AAA-related protocols such as DIAMETER can be used to exchange the required information to the appropriate management server or database.
Within the network element (NE), the layer management protocols pass the required information for the layer in question to the NE management plane, which processes (filters) the relevant information upward toward the OSS via the external management interface using one of several protocols mentioned previously. The OSS can then further collate and process this information to provide the service provider operations staff with a view of the status and performance of the overall network.
It is important to identify the relationship and synergy between the (transport) layer-specific management protocols and the management functions that coordinate and process this information and pass it along toward the OSS via the "external" management interfaces.
Layer management protocols can operate between individual network elements along the data path, such as alarm surveillance protocols including Alarm Inhibition (Indication) Signals (AIS), Remote Defect Indication (RDI), or loopback (for example, ICMP "ping") packets, etc. These protocols are designed to provide virtually instantaneous "in-band" information on the status and performance of the various flows and links.
However, this information has to be coordinated by the network management system to build an overall view of the operational state of the network, thereby enabling the service provider to ensure high performance and availability in support of SLAs.
As pointed out earlier, to some extent the NGN architecture model has blurred the traditional clear distinction often made between the management-plane functions and the control (signaling) plane, primarily because a common IP-based protocol stack is used to transport both types of messages.
For example, the use of DIAMETER (or RADIUS) to perform an authentication function from a database can be viewed as the responsibility of the management plane (that is, a security-related function). However, in the NGN model, such a process can also be viewed as part of the signaling procedures required to enable setup of a VoIP session (that is, an admission control function).
A systematic partitioning of such procedures into either control or management planes has not been undertaken so far. This aspect can sometimes result in some ambiguity as to whether a given interface can be classified as management- or control-related in the NGN model. In any case, the NGN PRM assumes that coordination between the control- and management-plane functions is necessary to support any typical NGN service category. This coordination needs to be accounted for when understanding the relationships between the various protocols involved in the control and management planes.
References
1. K. Ahmad and R. Kapoor, "The NGN Handbook," Cisco Systems, 2005
2. ITU-T FGNFN OD- 00244R2, "NGN-Framework Architecture (FRA) Version 7.1," Geneva, 2005. (Contained in ITU-T CM 13-D312.)
3. ITU-T IPCablecom J.series Recommendations, (for example, J.112) Geneva.
4. DSL Forum (www.dslforum.org) Technical Reports TR-058 and TR-092.
5. IETF RFC 3261 "Session Initiation Protocol."
6. ITU-T FGNGN- OD-00245R1, "IFN - IMS for NGN," Geneva, 2005. (Contained in ITU-T COM 13-D314.)