ATIS 0300100-2009 IP Network Disaster Recovery Framework.pdf

《ATIS 0300100-2009 IP Network Disaster Recovery Framework.pdf》由会员分享，可在线阅读，更多相关《ATIS 0300100-2009 IP Network Disaster Recovery Framework.pdf（37页珍藏版）》请在麦多课文档分享上搜索。

1、 TECHNICAL REPORT ATIS-0300100 IP NETWORK DISASTER RECOVERY FRAMEWORK ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 comp

2、anies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, numerous

3、 Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (

4、3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more information, p

5、lease visit . Notice of Disclaimer natural disasters; focused overloads; node or transmission failures which have widespread impact. Consequently it is important that this document include reference to or documentation of Next Generation Network (NGN) traffic management actions in overload situation

6、s whether triggered by a disaster or not. Network overload may effect interconnected resources and may produce a sustained interruption of telecommunications services that may have strategic significance to government, industry, and the general public. Network management actions should optimize the

7、integrity of IP networks while obtaining the maximum use of the IP network capability during the condition. To the greatest extent possible, these management actions should also preserve communications for priority services. Of particular importance when addressing interconnection disaster recovery

8、issues is the requirement for maintenance of emergency services. Emergency services also covers the telecommunications needs of societys dedicated resources for ensuring public safety; including police forces, fire fighting units, ambulance services and other health and medical services, as ATIS-030

9、0100 2 well as civil defence services. The telecommunications needs of such services have until now been satisfied by dedicated networks and equipment, often different for different services. With modern NGN technology it is possible and likely that such services will be integrated with the public t

10、elecommunications services and will include video and data services as well as voice. It is also desirable that such services receive preferential treatment (i.e., access, routing, session establishment, and so on) when disasters occur. Consequently NGN traffic management actions must be sensitive t

11、o this service inclusion and its priority. 2. Scope and Purpose 2.1 Scope This technical report provides a framework that encompass the complimentary network management actions that may be required by interconnected Network Providers of Next Generation Network (NGN) network resources in the event of

12、 a disaster condition. This implies the need to provide guidance on actions to perform in the case of a network overload condition on either side of an interconnection point. It focuses on SIP1-based NGN arrangements and interconnection points and technical specifications available at the time of de

13、velopment of this technical report. It defers consideration involving interworking to legacy circuit-based or non-SIP-based networks to some future date. This framework does not include a description of maintenance actions or management communications to be executed as result of trouble administrati

14、on business processes between interconnected NGN Network Providers. This framework also does not attempt to include an exhaustive description of maintenance actions (either scheduled or unscheduled) or management communications to be executed as result of a overload or failure condition triggered by

15、 a general network resource outage or service traffic anomaly within an NGN Network Providers jurisdiction. 2.2 Purpose The purpose of this technical report is to enumerate proactive or policy-driven network traffic management actions that should be performed prior to, during, and immediately follow

16、ing disaster conditions. Disaster conditions cause network overload. Consequently it is important that this document include reference to or documentation of NGN traffic management actions in overload situations whether triggered by a disaster or not. This document concentrates on providing guidelin

17、es applying to pairwise interconnection arrangements. 3. Abbreviations, Acronyms, and Definitions 3.1 Abbreviations and Acronyms 3GPP 3rdGeneration Partnership Program A-BGF Access Border Gateway Function ACD Automatic Call Distribution 1SIP refers to signaling and control mechanisms derived from us

18、e of the Session Initiation Protocol defined in RFC 3261. ATIS-0300100 3 AMR Adaptive Multi-Rate ANI Application Network Interface A-MGF Access Media Gateway Function AS Application Server ATIS Alliance for Telecommunication Industry Solutions B2B Business to Business BGCF Breakout Gateway Control F

19、unction C2B Customer to Business CAC Call Admission Control CCSP Call Control Signaling Path CPU Central Processing Unit CSN Circuit Switched Network DHS Department of Homeland Security DNS Domain Name System DS3 Digital Signal 3 DSCP DiffServ Code Point ENUM Electronic Number Mapping system EPC Egr

20、ess Packet Count ETS Emergency Telecommunications Service EVRC Enhanced Variable Rate Coding FCC Federal Communications Commission FQDN Fully Qualified Domain Name GETS Government Emergency Telecommunications Service GW Gateway HSS Home Subscriber Server IBCF Interconnect Border Control Function I-B

21、GF Interconnect Border Gateway Function I-CSCF Interconnect Call Session Control Function IEPS International Emergency Preference Scheme IETF Internet Engineering Task Force IMS IP Multimedia Subsystem IP Internet Protocol IPC Ingress Packet Count ISUP ISDN User Part ITU-T International Telecommunic

22、ation Union Telecommunication IWF InterWorking Function MGCF Media Gateway Control Function MLPP MultiLevel Precedence and Preemption MOS Mean Opinion Score MP Media Path MPLS Multi Protocol Label Switching MRB Media Resource Broker MRFC Multimedia Resource Function Controller MRFP Multimedia Resour

23、ce Function Processor MS Media Server NCC National Coordinating Center (for Telecommunications) NCS National Communications System NGN Next Generation Network NMS Network Management System NNI Network to Network Interface NOC Network Operations Center NS/EP National Security Emergency Preparedness O

24、AM Operations, Administration, Maintenance OAM Inter-domain protocol normalization and/or repair; Inter-domain protocol interworking; and Interaction with PDF for resource reservation, resource allocation, and/or other resource related information (e.g., the available resource parameters if the requ

25、ired resources are not available, QoS label, etc.). ATIS-0300100 8 The I-BGF is a packet gateway used to interconnect IMS core network with another IP network at the media level There may be one or multiple I-BGF in a core network. The I-BGF may support the following (not limited to): Media conversi

26、on (e.g., G.711 and AMR, T.38, EVRC, and G.711); Inter-domain IPv4/IPv6 conversion; Media encryption; and Fax/modem processing. An IWF is invoked by the IBCF when interworking between different signaling protocols (e.g., SIP and H.323) is required. The logical functions of the IBCF, I-BGF, and IWF m

27、ay be found in a single network element, commonly referred to as a Session Border Controller (SBC). 5.1.2 PSTN Gateway The Breakout Gateway Control Function (BGCF) processes requests for routing from an S-CSCF for the case when the S-CSCF has determined the session cannot be routed using DNS or ENUM

28、/DNS. The BGCF determines the next hop for routing the SIP message. For interworking with the PSTN, the BGCF determines the network in which the breakout is to occur. If breakout is to occur in the same network where the BGCF is located, then the BGCF shall select an MGCF. If the breakout is to occu

29、r in another network then the BGCF shall forward the session signaling to another BGCF in the selected network. The MGCF uses a Signaling Gateway Function (SGF) to perform interworking between a SIP based signaling network and an SS7 network. Interworking applies for call related signaling, ISUP, an

30、d non-call related signaling, TCAP. The MGCF uses a Trunk Media Gateway Function (T-MGF) to interconnect bearer channels from the PSTN with media streams from RTP sessions. The logical function of BGCF is commonly referred to as a media gateway controller. The logical function of SGF is commonly ref

31、erred to as a signaling gateway. The logical function of T-MGF is commonly referred to as a media gateway. Combinations of logical functions are dependent on individual implementation. 5.2 Network-to-Network Interface Figure 3 below illustrates an IP Network-to-Network Interface (NNI) between carrie

32、rs using SIP. The model in Figure 3 focuses specifically on points of interoperability between technologies and service provider domains. The interconnection concept is based on a specific interface entity, a called session border function. The session border function performs multiple functions des

33、igned to help Voice over IP (VoIP) carriers to interface with a customer or another carriers network. For network-to-network interconnection, a session border function may perform the following functions (not exhaustive): Call control signaling, e.g., SIP ATIS-0300100 9 Bearer control signaling for

34、the control of media streams Interaction between call control and bearer control functions Call/session routing Traffic and QoS management Screening Security Network topology hiding from the interconnected networks Media stream mapping (e.g., transcoding). Figure 3 - Architectural Diagram of Interco

35、nnected VoIP/Multimedia Networks End to End As telecom networks migrate from TDM circuit switched to IP, the IP network-to-network interface (NNI) for VoIP, video, and data will be the critical interface between carriers. Inter-networking traffic will be exchanged over existing peering interconnecti

36、on used for other IP traffic, dedicated IP peering interconnection (e.g., VPNs), or via transit IP networks. It is essential in an inter-networking environment between different network operators and technologies that adequate network performance is achieved for all IP applications. Appropriate netw

37、ork management methods and procedures will need to be developed between various network operators to ensure the adequate service performance of the IP connections and among distinct network technologies. In this environment SIP is the protocol used for call control signaling. RTP is used for voice a

38、nd video transport. Other transport protocols may be used for data applications. There may also be data oriented call control in addition to SIP oriented call control occurring across the NNI. For example, a network based service may allow a user to initiate calls or control the disposition of incom

39、ing calls through a web browser interface on an Application server using http. Logical interfaces associated with the call control, call routing, and bearer functional entities will be utilized to support interconnection between service provider networks in a peering environment. 5.3 Network Congest

40、ion Control Congestion control refers to all network actions employed to minimize the intensity, spread and duration of congestion. A SIP network (currently the preferred signaling protocol for NGN implementations) may be overloaded by a number of triggers including empergency-induced call volume, b

41、y transient crowd effects, and by denial of service attacks. The SIP network is said to suffer from “overload” when proxies and user agents have insufficient resources to complete the processing of a request or a response An individual server is said to suffer from “overload” when the number of SIP

42、messages it receives exceeds the number of messages it can process. NGN ATIS-0300100 10 overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse. Overload can pose a serious problem for a net

43、work of SIP servers and so it is expected that some remedy would be supplied at the protocol level. The SIP protocol did provide a mechanism for overload control through its 503 (Service Unavailable) response code which is used to reject a session request and cancel any related outstanding retransmi

44、ssion timers3. Basically this code allows a server to tell an upstream element that it is overloaded and to suspend or stop subsequent session requests. However, numerous problems have been identified with this mechanism (whether implemented with the Retry-After parameter or not). Because of these c

45、oncerns, analysis of potential distributed overload mechanisms has been performed. In distributed overload control, SIP servers are enabled to provide overload control feedback to servers that are further upstream in a SIP server network. This feedback can be used by the upstream servers to reduce l

46、oad to an amount that does not cause downstream servers to be overloaded. Overload feedback can be conveyed in a SIP response header. The overload control feedback loop can be applied to the path of a SIP request hop-by-hop (individually between each pair of SIP servers) or end-to-end as a single co

47、ntrol loop that stretches across the entire path from UAC to UAS. Although these distributed overload control mechanisms offer promise for more effective overload management, extensions to the SIP protocol have not yet been standardized to realize their benefit. In their absence, carriers must rely

48、on non-real-time OAM measures and flow control mechanisms as described later. SIP applications involve at least five different resources that may become scarce and congested during emergencies. In order to improve emergency response, it may become necessary to prioritize access to such resources dur

49、ing periods of emergency-induced resource scarcity. Resource types for which prioritized access may be useful include: Gateway resources: the number of channels (trunks) on a Circuit-Switched Network (CSN) gateway is finite. Resource prioritization may prioritize access to these channels, by priority queuing or preemption. CSN resources: Resources in the CSN itself, away from the access gateway, may be congested. This is the domain of traditional resource prioritization mechanisms such as MLPP and GETS, where circuits are granted to ETS commun