Welcome to TelecomFYI.com

Search Articles  



 
 

ATM Signaling and Addressing - Part One

Attention: open in a new window. E-mail

Because ATM is a connection-oriented service, specific signaling protocols and addressing structures, as well as protocols to route ATM connection requests across the ATM network, are needed. The following sections describe the role of signaling and addressing in ATM networking.

Signaling

ATM connection services are implemented using permanent and switched virtual connections. In the case of a permanent virtual connection (PVC), the VPI/VCI values at each switching point in the connection must be manually configured. While this can be a tedious process, it only needs to be done once, because once the connection is set up, it remains up permanently. PVCs are a good choice for connections that are always in use or are in frequent, high demand. However, they require labor-intensive configuration, they are not very scalable, and they are a good solution for infrequent or short-lived connections. Switched virtual connections (SVCs) are the solution for the requirements of on-demand connections. They are set up as needed and torn down when no longer needed. To achieve this dynamic behavior, SVCs use signaling: End systems request connectivity to other end systems on an as needed basis and, provided that certain criteria are met, the connection is set up at the time of request. These connections are then dynamically torn down if the connections are not being used, freeing network bandwidth, and can be brought up again when needed.

Note Because SVCs require signaling, they can normally be used only with ATM devices that arecapable of signaling. Your ATMswitch router supports the standard signaling protocols described in this article.

In addition to permanent and switched virtual connections, there is a third, hybrid type. Called soft PVC and soft PVP, these connections are permanent but, because they are set up through signaling, they can ease setup of PVCs and PVPs and can reroute themselves if there is a failure in the link.

Connection Setup and Signaling

Figure 2-1 demonstrates how a basic SVC is set up from Router A (the calling party) to Router B(the called party) using signaling. The steps in the process are as follows:

1 Router A sends a signaling request packet to its directly connected ATMswitch (ATM switch 1). This request contains the ATM address of both calling and called parties, as well as the basic traffic contract requested for the connection.

2 ATM switch 1 reassembles the signaling packet from Router A and then examines it.

3 If ATM switch 1 has an entry for Router B’s ATM address in its switch table, and it can accommodate the QoS requested for the connection, it reserves resources for the virtual connection and forwards the request to the next switch (ATM switch 2) along the path.

4 Every switch along the path to Router B reassembles and examines the signaling packet, then forwards it to the next switch if the traffic parameters can be supported on the ingress and egress interfaces. Each switch also sets up the virtual connection as the signaling packet is forwarded. If any switch along the path cannot accommodate the requested traffic contract, the request is rejected and a rejection message is sent back to Router A.

5 When the signaling packet arrives at Router B, Router B reassembles it and evaluates the packet. If Router B can support the requested traffic contract, it responds with an accept message. As the accept message is propagated back to Router A, the virtual connection is completed.

Note Because the connection is set up along the path of the connection request, the data also flows along this same path.

When it is time to tear down the connection, another sequence of signals is used:

1 Either the calling party or called party sends a release message to the ATM network.

2 The ATM network returns a release complete message to the called party.

3 The ATM network sends a release complete message to the calling party. The dynamic call teardown is complete.


ATM Signaling Protocols—UNI and NNI

ATM signaling protocols vary by the type of ATM network interface, as follows:

• User-Network Interface (UNI) signaling—used between an ATM end-system and ATM switch across UNI links; UNI signaling can also be used between two ATM switches

• Network-Network Interface (NNI) signaling—used between ATM switches across NNI links. UNI signaling in ATM defines the protocol by which SVCs are set up dynamically by the ATM devices in the network. NNI signaling is part of the Private Network-Network Interface (PNNI)specification, which includes both signaling and routing. See the chapter "ATM Routing with IISP and PNNI."

Note The UNI specifications include physical layer, Integrated Local Management Interface(ILMI), and traffic management, in addition to signaling.

The ATM Forum has the task of standardizing the signaling procedures. The ATM Forum UNI specifications are based on the Q.2931 public network signaling protocol developed by the ITU-T. The Q.2931 protocol specifies a call control message format that carries information such as message type (setup, call proceeding, release, and so on) and information elements (IEs), which include addresses and QoS.

All the IEs appropriate to an interface type in the signaling message are transmitted by default. On

the ATMswitch router, you can selectively disable the forwarding of individual IEs on an interface.

See the ATM Switch Router Software Configuration Guide for details.

The UNI specifications are grouped as follows:

• UNI 3.x—consists of two sets of interoperable specifications, UNI 3.0 and UNI 3.1

• UNI 4.0—includes UNI 3.x specifications and adds new features not supported in UNI 3.x

The original UNI signaling specification, UNI 3.0, provided for the following features:

• Signaling for point-to-point connections and point-to-multipoint connections

• Support for bandwidth symmetric and bandwidth asymmetric traffic

UNI 3.1 includes the provisions of UNI 3.0 but provides for a number of changes, a number of which were intended to bring the earlier specifications into conformance with ITU-T standards: UNI 4.0 replaced an explicit specification of the signaling protocol with a set of deltas between it and ITU-T signaling specifications. In general, the functions in UNI 4.0 are a superset of UNI 3.1, and include both a mandatory core of functions and many optional features.

• Anycast signaling—allows connection requests and address registration for group addresses, where the group address can be shared among multiple end systems; the group address can represent a particular service, such as a configuration or name server.

• Explicit signaling of QoS parameters—maximum cell transfer delay (MCTD), peak-to-peak cell delay variation (ppCDV), and cell loss ratio (CLR) can be signaled across the UNI for CBR and VBR SVCs.

• Signaling for ABR connections—many parameters can be signaled to create ABR connections.

• Virtual UNI—provides for using one physical UNI with multiple signaling channels. For example, several end stations can connect through a multiplexor; the multiplexor connects via UNI to an ATM switch. In this case there are multiple signaling channels being used by the end stations, but only one UNI (the virtual UNI).

• PNNI—specifies signaling and routing protocols across the NNI. PNNI is an optional addition to the UNI 4.0 specification; for detailed information see the chapter "ATM Routing with IISP and PNNI."

The following optional features in UNI 4.0 are not supported on the ATM switch router:

• Proxy signaling—allows a device, called a proxy signaling agent, to signal on behalf of other devices. For example, a router might signal for devices behind it that do not support signaling. Another use for proxy signaling would be a video server with aggregated links (say, three 155 Mpbs links aggregated for the 400 Mpbs required by video); in this case, where there is really just one connection, one of the links would signal on behalf of all three.

• Signaling for point-to-multipoint connections—leaf initiated joins are supported.

Note Your ATM switch router supports UNI 3.0, 3.1, and 4.0.

Multipoint-to-Point Funnel Signaling

TheATMswitch router supports the Microsoft Corporation Proprietary Funnel Join (or FlowMerge) Protocol via the multipoint-to-point funnel signaling (funneling) feature over the UNI. This feature improves the scalability of video-on-demand services, in which multiple video transmitting sources converge on a single virtual connection such that it looks like a point-to-point connection. Multipoint-to-point funnel signaling (funneling) works by merging multiple incoming SVCs into a single outgoing SVC. An incoming SVC is called a leaf SVC, and the outgoing SVC is called the funnel SVC.                                                                                                                                   The ATM switch router performs funnel merging on SVCs that originate from the UNI. With the exception of the funnel switch (see Figure 2-2), the multipoint-to-point funnel appears to the network as a point-to-point connection.

Note This feature is an extension of UNI 3.1 and is not supported in UNI 4.0 signaling. The ATM accounting feature is not supported for funnel SVCs.

Figure 2-2 illustrates multipoint-to-point funnel signaling.

Mulitpoint-to-point funnel signaling requires no configuration. For funneling to operate, traffic parameters must be the same for all the SVC leaves on a particular funnel call. The aggregate bandwidth of the source links (SVC leaves) cannot exceed the bandwidth allocated to the funnel link.A maximum of 255 links (leaf SVCs) can join the funnel link. The sources perform arbitration to avoid overloading of the funnel link by the running application. When the ATM switch router receives a setup message containing a leaf-initiated join information element, the ATM switch router searches for funnel SVCs with existing connections to the destination. The leaf-initiated join information element connection ID and the destination ATM address uniquely identify each funnel SVC. If a funnel SVC to the same destination arrives with the same leaf-initiated join element connection ID, as one that is already present, the ATM switch router checks to see if the traffic parameters specified in the incoming setup message are the same as those in the funnel SVC. If the parameters are the same, then the leaf is joined to the funnel SVC, and the connection is acknowledged. If the traffic parameters are different, then the setup request is denied. If a funnel SVC to the specified destination is not available when an incoming setup message arrives, then a point-to-point SVC is set up to transmit the message.


Addressing

ATM addresses are needed for purposes of signaling when setting up switched connections. ATM addresses are also used by the Integrated Local Management Protocol (ILMI, formerly Interim Local Management Protocol) to learn the addresses of neighboring switches.

ATM Address Formats

The ITU-T long ago settled on telephone number-like addresses, called E.164 addresses or E.164 numbers, for use in public ATM (B-ISDN) networks. Since telephone numbers are a public (and expensive) resource, theATMForum set about developing a private network addressing scheme. The ATM Forum considered two models for private ATM addresses: a peer model, which essentially treats theATMlayer as a peer of existing network layers, and a subnetwork, or overlay, model, which decouples the ATMlayer from any existing protocol and defines for itself an entirely new addressing structure.

The ATM Forum settled on the overlay model and defined an ATM address format based on the semantics of an OSI Network Service Access Point (NSAP) address. This 20-byte private ATM address is called an ATM End System Address (AESA), or ATM NSAP address (though it is technically not a real NSAP address). It is specifically designed for use with private ATMnetworks, while public networks typically continue to use E.164 addresses.

The general structure of NSAP format ATM addresses, shown in Figure 2-3, is as follows:

• An initial domain part (IDP)—consists of two elements: an authority and format identifier (AFI)that identifies the type and format of the second element, the initial domain identifier (IDI). The IDI identifies the address allocation and administration authority.

• A domain specific part (DSP)—contains the actual routing information in three elements: a high-order domain specific part (HO-DSP), an end system identifier (ESI), which is the MAC address, and NSAP selector (SEL) field, used to identify LANE components.

Figure 2-3 Private ATM Network Address Formats

Private ATM address formats are of three types that differ by the nature of their AFI and IDI (see Figure 2-3):

• DCC format (AFI=39)—the IDI is a Data Country Code (DCC). DCC addresses are administered by the ISO national member body in each country.

• ICD format (AFI=47)—the IDI is an International Code Designator (ICD). ICD address codes identify particular international organizations and are allocated by the British Standards Institute.

• NSAP encoded E.164 format (AFI=45)—the IDI is an E.164 number.

Note There are two types of E.164 addresses: the NSAP encoded E.164 format and the E.164 native format, sometimes called an E.164 number, used in public networks.

A sample ATM address, 47.00918100000000E04FACB401.00E04FACB401.00, is shown in Figure 2-4. The AFI of 47 identifies this address as a ICD format address.

Choosing an Address Format

The ATM Forum specifications through UNI 4.0 only specify these three valid types of AFI. However, future ATM Forum specifications will allow any AFI that has binary encoding of the Domain Specific Part (DSP) and a length of 20 octets. Although your Cisco ATMswitch router ships with an autoconfigured NSAP format ATM address of the ICD type, similar to the one shown in Figure 2-4, the ATM switch router does not restrict the AFI values; you can use any of the valid formats.

The ATMForum recommends that organizations or private network service providers use either the DCC or ICD formats to form their own numbering plan. NSAP encoded E.164 format addresses are used for encoding E.164 numbers within private networks that need to connect to public networks that use native E.164 addresses, but they can also be used by some private networks. Such private networks can base their own (NSAP format) addressing on the E.164 address of the public UNI to which they are connected and take the address prefix from the E.164 number, identifying local nodes by the lower order bits.


Polls

test poll
asdaasdasdadasdddadadadadadadadadadadadadasda
asdaasdasdadasdddadadadadadadadadadadadadasda
asdaasdasdadasdddadadadadadadadadadadadadasda
asdaasdasdadasdddadadadadadadadadadadadadasda
asdaasdasdadasdddadadadadadadadadadadadadasda
asdaasdasdadasdddadadadadadadadadadadadadasda

Username Password Remember Me Forgot your Password?

Telecom Articles