atmsig.gif (2737 bytes)

View this file in pdf format.

Signalling is the process by which ATM users and the network exchange the control of information, request the use of network resources, or negotiate for the use of circuit parameters. The VPI/VCI pair and requested bandwidth are allocated as a result of a successful signalling exchange.

The protocols illustrated below support connection control signalling. These messages are sent over the Signalling ATM Adaptation Layer (SAAL), which ensures their reliable delivery. The SAAL is divided into a Service Specific Part and a Common Part. The Service Specific Part is further divided into a Service Specific Coordination Function (SSCF), which interfaces with the SSCF user; and a Service Specific Connection-Oriented Protocol (SSCOP), which assures reliable delivery.

 

User-Network Signalling

SAAL

UNI SSCF

SSCOP

AAL Type 5 Common Part

ATM Layer

Physical Layer

ATM signalling protocol stack

The UNI signalling protocols within the SAAL are responsible for ATM call and connection control, including call establishment, call clearing, status enquiry, and point-to-multipoint control.

UNI 3.0, UNI 3.1, Q.2931, UNI 4.0, IISP, PNNI, Q.SAAL and SPANS are described in this chapter. Refer to Chapter 12 for information on ILMI which is used for address registration.

 

UNI 3.x Signalling

ftp://ftp.atmforum.com/pub/approved-specs/

A signalling message uses the Q.931 message format. It is made up of a message header and a variable number of Information Elements (IEs). This is shown in the following figure:

Message header

IE

IE

...

IE

ATM signalling message structure

The message header is shown in the following diagram:

 

Bit
8 7 6 5 4 3 2 1 Octet
Protocol discriminator (9 for Q.2931 messages) 1
0 0 0 0 Length of call reference value 2
Flag Call reference value 3
Call reference value (continued) 4
Call reference value (continued) 5
Message type 6
Message type (continued) 7
Message length 8
Message length (continued) 9
Variable length Information Elements as required etc.

ATM signalling message structure

 

Protocol discriminator
Distinguishes Messages for user-network call control from other messages.

Call reference
Unique number for every ATM connection which serves to link all signalling messages relating to the same connection. It identifies the call at the local user network interface to which the particular message applies. The call reference is comprised of the call reference value and the call reference flag. The call reference flag indicates who allocated the call reference value.

Message type
The message may be of the following types:

Call establishment messages:
CALL PROCEEDING, sent by the called user to the network or by the network to the calling user to indicate initiation of the requested call.
CONNECT, sent by the called user to the network and by the network to the calling user to indicate that the called user accepted the call.
CONNECT ACKNOWLEDGE, sent by the network to the called user to indicate that the call was awarded and by the calling user to the network.
SETUP, sent by the calling user to the network and by the network to the calling user to initiate a call.

Call clearing messages:
RELEASE, sent by the user to request that the network clear the connection or sent by the network to indicate that the connection has cleared.

RELEASE COMPLETE, sent by either the user or the network to indicate that the originator has released the call reference and virtual channel.
RESTART, sent by the user or the network to restart the indicated virtual channel.
RESTART ACKNOWLEDGE, sent to acknowledge the receipt of the RESTART message.

Miscellaneous messages:
STATUS, sent by the user or network in response to a STATUS ENQUIRY message.
STATUS ENQUIRY, sent by the user or the network to solicit a STATUS message.

Point-to-Multipoint messages:
ADD PARTY, adds a party to an existing connection.
ADD PARTY ACKNOWLEDGE, acknowledges a successful ADD PARTY.
ADD PARTY REJECT, indicates an unsuccessful ADD PARTY.
DROP PARTY, drops a party from an existing point-to-multipoint connection.
DROP PARTY ACKNOWLEDGE, acknowledges a successful DROP PARTY.

Message length
The length of the contents of a message.

Information Elements
Described below.

Example of UNI signalling decode

Types of Information Elements

There are several types of information elements. Some may appear only once in the message; others may appear more than once. Depending on the message type, some information elements are mandatory and some are optional. The order of the information elements does not matter to the signalling protocol. The information elements in UNI 3.0 are listed in the following table:

IE Description Max. No.
Cause Gives the reason for certain messages. For example, the Cause IE is part of the release message, indicating why the call was released. 2
Call state Indicates the current state of the call. 1
Endpoint reference Identifies individual endpoints in a point-to-multipoint call. 1
Endpoint state Indicates the state of an endpoint in a point-to-multipoint call. 1
AAL parameters Includes requested AAL type and other AAL parameters. 1
ATM user cell rate Specifies traffic parameters. 1
Connection identifier Identifies the ATM connection and gives the VPI and VCI values. 1
Quality of Service parameter Indicates the required Quality of Service class for the connection. 1
Broadband high-layer information Gives information about the high-layer protocols for compatibility purposes. 1
Broadband bearer capacity Requests a service from the network (such as CBR or VBR link, point-to-point and point-to-multipoint link). 1
Broadband low-layer information Checks compatibility with layer 2 and 3 protocols. 3
Broadband locking shift Indicates a new active codeset. -
Broadband non-locking shift Indicates a temporary codeset shift. -
Broadband sending complete Indicates the competition of sending the called party number. 1
Broadband repeat indicator Indicates how IEs which are repeated in the message should be handled. 1
Calling party number Origin of the call. 1
Calling party subaddress Subaddress of calling party. 1
Called party number Destination of the call. 1
Called party subaddress Subaddress of the called party. 1
Transit network selection Identifies one requested transit network. 1
Restart indicator Identifies which facilities should be restarted (e.g., one VC, all VCs). 1

Types of IEs

For further reference about the exact structure and parameters of the IEs, refer to the ATM Forum, ATM User-Network Interface Specifications 3.0 and 3.1.

 

ITU Q.2931 Signalling

http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2931_29825.html

This is the ITU version of signalling. The Q.2931 signalling protocol specifies the procedures for the establishment, maintenance and clearing of network connections at the B-ISDN user network interface. The procedures are defined in terms of messages exchanged. The basic capabilities supported by Q.2931 Signalling are as follows:

  • Demand (switched virtual) channel connections.
  • Point-to-point switched channel connections.
  • Connections with symmetric or asymmetric bandwidth requirements.
  • Single-connection (point-to-point) calls.
  • Basic signalling functions via protocol messages, information elements and procedures.
  • Class X, Class A and Class C ATM transport services.
  • Request and indication of signalling parameters.
  • VCI negotiation.
  • Out-of-band signalling for all signalling messages.
  • Error recovery.
  • Public UNI addressing formats for unique identification of ATM endpoints.
  • End-to-end compatibility parameter identification.
  • Signalling interworking with N-ISDN and provision of N-ISDN services.
  • Forward compatibility.

The message types for Q.2931 are the same as in UNI 3.0/3.1, with the exception of the point-to-multipoint messages which are not supported. The following are new signalling messages specific to Q.2931:

ALERTING, sent by the called user to the network and by the network to the calling user indicating that the called user alerting has been initiated.

PROGRESS, sent by the user or the network to indicate the progress of a call in the event of interworking.

SETUP ACKNOWLEDGE, sent by the network to the calling user or by the called user to the network to indicate that call establishment has been initiated.

INFORMATION, sent by the user or the network to provide additional information.

NOTIFY, sent by the user or by the network to indicate information pertaining to a call connection.

The information elements in Q.2931 are as follows:

  • Called party number.
  • Called party sub-address.
  • Transit network selection.
  • Restart indicator.
  • Narrow-band low layer compatibility.
  • Narrow-band high layer compatibility.
  • Broadband locking shift.
  • Broadband non-locking shift.
  • Broadband sending complete.
  • Broadband repeat indicator.
  • Calling party number.
  • Calling party sub-address.
  • ATM adaptation layer parameters.
  • ATM traffic descriptor.
  • Connection identifier.
  • OAM traffic descriptor.
  • Quality of Service parameter.
  • Broadband bearer capability.
  • Broadband Low Layer Information (B-LLI).
  • Broadband High Layer Information (B-HLI).
  • End-to-end transit delay.
  • Notification indicator.
  • Call state.
  • Progress indicator.
  • Narrow-band bearer capability.
  • Cause.

 

UNI 4.0 Signalling

http://www-comm.itsi.disa.mil/atmf/sig.html#af10.1

UNI 4.0 provides the signalling procedures for dynamically establishing, maintaining and clearing ATM connections at the ATM User-Network Interface. UNI 4.0 applies both to Public UNI (the interface between endpoint equipment and a public network) and private UNI (the interface between endpoint equipment and a private network).

The following new features are available within the UNI 4.0 signalling protocol:

  • Leaf initiated join.
  • Enhanced ATM traffic descriptor.
  • Available bit rate capability.
  • Individual QoS parameters.
  • Narrow ISDN over ATM.
  • AnyCast capability.
  • New information elements.
  • New VPI/VCI options.
  • Proxy signalling capability.
  • Virtual UNIs.
  • Supplementary services such as direct dialing in, multiple subscriber number, calling line identification presentation, calling line identification restriction, connected line identification presentation, connected line identification rest, user-to-user signalling.
  • Error handling for instruction indicators.
  • Using setup for adding parties.
  • Both NSAP and ASTM endsystem addresses.
  • Network can support leaves that do not support P-PM.

The message types for UNI 4.0 are the same as in Q.2931, with the exception of the SETUP ACKNOWLEDGE and INFORMATION messages which are not supported. The following are new signalling messages specific to UNI 4.0: LEAF SETUP REQUEST and Leaf Setup Failure.

The following are the information elements contained in UNI 4.0:

  • Narrowband bearer capability.
  • Cause.
  • Call state.
  • Progress indicator.
  • Notification indicator.
  • End-to end transit delay.
  • Connected number.
  • Connected subaddress.
  • Endpoint reference.
  • Endpoint state.
  • ATM adaptation layer parameters.
  • ATM traffic descriptor.
  • Connection identifier.
  • Quality of service parameter.
  • Broadband high layer information.
  • Broadband bearer capability.
  • Broadband low layer information.
  • Broadband locking shift.
  • Broadband non-locking shift.
  • Broadband repeat indicator.
  • Calling party number.
  • Calling party subaddress.
  • Called party number.
  • Called party subaddress.
  • Transit network selection.
  • Restart indicator.
  • Narrowband low layer compatibility.
  • Narrowband high layer compatibility.
  • Generic identifier transport.
  • Minimum acceptable traffic descriptor.
  • Alternative ATM traffic descriptor.
  • ABR setup parameters.
  • Leaf initiated join call identifier.
  • Leaf initiated join parameters.
  • Leaf sequence number.
  • Connection scope selection.
  • ABR additional parameters.
  • Extended QoS parameters.

 

Q.SAAL

Q. 2110 http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2110_27521.html
Q.2144 http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2144_33084.html
Q.2100 http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2100_27509.html
RFC1953 http://www.cis.ohio-state.edu/htbin/rfc/rfc1953.html

Following is the structure for each Q.SAAL message type.

BGN PDU (Begin)
The BGN PDU is used to initially establish an SSCOP connection or reestablish an existing SSCOP connection between two peer entities. The BGN requests the clearing of the peer’s transmitter and receiver buffers, and the initialization of the peer’s transmitter and receiver state variables.

Bytes

1

2

3

4

1

N(UU)

2

Rsvd

S

PDU Type

N(MR)

8 7 6

5

4 3 2 1

Begin PDU (BGN PDU)

BGAK PDU (Begin Acknowledge)
The BGAK PDU is used to acknowledge the acceptance of a connection request by the peer entity.

Bytes

1

2

3

4

1

N(UU)

2

Rsvd

PDU Type

N(MR)

8 7 6 5

4 3 2 1

Begin Acknowledged PDU (BGAK PDU)

BGREJ PDU (Begin Reject)
The BGREJ PDU is used to reject the connection establishment of the peer SSCOP entity.

Bytes

1

2

3

4

1

N(UU)

2

Rsvd

PDU Type

Reserved

8 7 6 5

4 3 2 1

Begin Reject PDU (BGREJ PDU)

 

END PDU (End)
The END PDU is used to release an SSCOP connection between two peer entities.

Bytes

1

2

3

4

1

N(UU)

2

Rsvd

S

PDU Type

Reserved

8 7 6

5

4 3 2 1

End PDU (END PDU)

ENDAK PDU (End Acknowledge)
The ENDAK PDU is used to confirm the release of an SSCOP connection that was initiated by the peer SSCOP entity.

Bytes

1

2

3

4

1

Rsvd

PDU Type

Reserved

8 7 6 5

4 3 2 1

End Acknowledgement (ENDAK PDU)

RS PDU (Resynchronization Command)
The RS PDU is used to resynchronize the buffers and data transfer state variables in the transmit direction of an SSCOP connection.

Bytes

1

2

3

4

1

N(UU)

2

Rsvd

PDU Type

Reserved

8 7 6 5

4 3 2 1

Resynchronization PDU (RS PDU)

RSAK PDU (Resynchronization Acknowledgement)
The RSAK PDU is used to acknowledge the resynchronization of the local receiver stimulated by the received RS PDU.

Bytes

1

2

3

4

1

Rsvd

PDU Type

Reserved

8 7 6 5

4 3 2 1

Resynchronization acknowledge PDU (RSAK PDU)

SD PDU (Sequenced Data)
The SD PDU is used to transfer, across an SSCOP connection, sequentially numbered PDUs containing information fields provided by the SSCOP user.

Bytes

1

2

3

4

1

Information (maximum k bytes)

. . .

PAD (0-3 Bytes)

n

PL

Rsd

PDU Type

N(S)

8 7

6 5

4 3 2 1

Sequenced data PDU (SD PDU)

SDP PDU (Sequenced Data with Poll)
The SDP PDU is used to transfer, across an SSCOP connection, sequentially numbered PDUs containing information fields provided by the SSCOP user. The SDP PDU also contains a poll request that is used to stimulate the transmission of a STAT PDU. Therefore, an SDP PDU is the functional concatenation of an SD PDU and a POLL PDU.

Bytes

1

2

3

4

1

Information (maximum k bytes)

. . .

PAD (0-3 Bytes)

Reserved

N(PS)

n

PL

Rsd

PDU Type

N(S)

8 7

6 5

4 3 2 1

Sequenced data with poll PDU (SDP PDU)

POLL PDU (Status Request)
The POLL PDU is used to request, across an SSCOP connection, status information about the peer SSCOP entity. It contains a sequence number for use in the retransmission of lost SD or SDP PDUs.

Bytes

1

2

3

4

1

Reserved

N(PS)

2

Rsvd

PDU Type

N(S)

8 7 6 5

4 3 2 1

Poll PDU (POLL PDU)

STAT PDU (Solicited Status Response)
The STAT PDU is used to respond to a status request (POLL PDU) received from a peer SSCOP entity. It contains information regarding the reception status of SD or SDP PDUs, credit information for the peer transmitter, and the sequence number of the POLL PDU to which it is in response.

Bytes

1

2

3

4

1

PAD

List element 1 (a SD PDU N(S))

2

PAD

List element 2

...

.
.
.

.
.
.

L

PAD

List element L

L+1

PAD

N(PS)

L+2

PAD

N(MR)

L+3

Rsvd

PDU Type

N(R)

8 7 6 5

4 3 2 1

Solicited status PDU (STAT PDU)

USTAT PDU (Unsolicited Status Response)
The USTAT PDU is used to respond to a detection of a new missing SD or SDP PDU, based on the examination of the sequence number of the SD or SDP PDU. It contains information regarding the reception status of SD or SDP PDUs and credit information for the peer transmitter.

Bytes

1

2

3

4

1

PAD

List element 1 (a SD PDU N(S))

2

PAD

List element 2

3

PAD

N(MR)

4

Rsvd

PDU Type

N(R)

8 7 6 5

4 3 2 1

Unsolicited status PDU (STAT PDU)

UD PDU (Unnumbered Data)
The UD PDU is used for unassured data transfer between two SSCOP users. When an SSCOP user requests unacknowledged information transfer, the UD PDU is used to send information to the peer without affecting SSCOP status or variables. UD PDUs do not carry a sequence number and therefore, the UD PDU may be lost without notification.

Bytes

1

2

3

4

1

Information (maximum k bytes)

. . .

PAD (0-3 Bytes)

n

PL

Rsd

PDU Type

Reserved

8 7

6 5

4 3 2 1

Unit data PDU (UD PDU) / management data (MD PDU)

MD PDU (Management Data)
The MD PDU is used for unassured management data transfer between two SSCOP entities. When a management entity requests unacknowledged information transfer, the MD PDU is used to send information to the peer management entity without affecting SSCOP status or variables. MD PDUs do not carry a sequence number and therefore, the MD PDU may be lost without notification. (see UD PDU diagram above).

 

IISP

IISP (Interim Interswitch Signalling Protocol) is a protocol that has been devised to provide signalling between switches from multiple vendors. It has been developed as a stopgap solution, until the more sophisticated PNNI (Private Network-to-Network Interface) specification is complete. There is no migration path from IISP to PNNI.

IISP uses UNI 3.1 signalling procedures as does PNNI. However, the switches using IISP are not peers, i.e., one switch functions as the network node and the other as an end-station. There is no support for dynamic distribution of routing information.

 

PNNI Signalling and Routing

http://www-comm.itsi.disa.mil/atmf/pnni.html#af55

PNNI (Private Network-to-Network Interface), is a hierarchical, dynamic link-state routing protocol. It is designed to support large-scale ATM networks. The PNNI protocol uses VPI/VCI 0,18 for its messages. In addition, it uses signalling messages to support connection establishment across multiple networks. The signalling is based on UNI 4.0 and Q.2931. Specific information elements were added to UNI 4.0 in order to support the routing process of PNNI.

PNNI Signalling

PNNI Signalling contains the procedure to dynamically establish, maintain and clear ATM connections at the private network to network interface or network node interface between 2 ATM networks or 2 ATM network nodes. The PNNI signalling protocol is based on the ATM forum UNI specification and on Q.2931.

PNNI Messages include:
ALERTING, CALL PROCEEDING, CONNECT, SETUP, RELEASE, RELEASE COMPLETE, NOTIFY, STATUS, STATUS ENQUIRY, RESTART, RESTART ACKNOWLEDGE, STATUS, ADD PARTY, ADD PARTY ACKNOWLEDGE, PARTY ALERTING, ADD PARTY REJECT, DROP PARTY, DROP PARTY ACKNOWLEDGE.

The following messages for ATM call connection control for the support of 64 Kbits based ISDN circuit code services are transported without change across the PNNI:
ALERTING, CONNECT PROGRESS, SETUP, RELEASE.

The following message types supported by Q.2931 are not supported by PNNI:
CONNECT ACKNOWLEDGE, SETUP ACKNOWLEDGE, INFORMATION.

PNNI signalling decode

PNNI Routing

The structure of the PNNI header is shown in the following illustration:

Packet type

Packet length

Prot ver

Newest ver

Oldest ver

Reserved

2

2

1

1

1

1

PNNI header structure

Packet type
The following packet types are defined:

Hello Sent by each node to identify neighbor nodes belonging to the same peer group.
PTSP PNNI Topology State Packet. Passes topology information between groups.
PTSE PNNI Topology State Element (Request and Ack). Conveys topology parameters such as active links, their available bandwidth, etc.
Database Summary Used during the original database exchange between two neighboring peers.

Packet length
The length of the packet.

Prot ver
Protocol Version. The version according to which this packet was formatted.

Newest ver / Oldest ver
Newest version supported / oldest version supported. The newest version supported and the oldest version supported fields are included in order for nodes to negotiate the most recent protocol version that can be understood by both nodes exchanging a particular type of packet.

Information groups
The following information groups are found in PNNI packets:

Hello:
Aggregation token
Nodel hierarchy list
Uplink information attribute
LGN horizontal link
Outgoing resource availability
Optional GCAC parameters
System capabilities

PTSP:
PTSE
Nodal state parameters
Nodal information group
Outgoing resource availability
Incoming resource availability
Next higher level binding
Optional GCAC parameters
Internal reachable ATM address
Exterior reachable ATM addresses
Horizontal links
Uplinks
Transit network ID
System capabilities

PTSE Ack:
Nodal PTSE Ack
System capabilities

Database Summary:
Nodal PTSE summaries
System capabilities

PTSE Request:
Requested PTSE header
System capabilities

PNNI routing decode

 

B-ICI

http://www-comm.itsi.disa.mil/atmf/bici.html#af13.3

B-ICI, a BISDN Inter Carrier Interface, is an interface connecting two different ATM based public network providers or carriers. This is necessary in order to facilitate end-to-end national and international ATM/BISDN services. The B-ICI specification also includes service specific functions above the ATM layer required to transport, operate and manage a variety of intercarrier services across the B-ICI.

The protocols in this group include: Q.2140 and B-ISUP.

B-ISUP

The structure of the B-ISUP header is shown in the following illustration:

Routing label

Type code

Message length

Compatibility

Message

4

1

2

1

variable

B-ICI header structure

Routing label
This is the same for each message on a specific ATM virtual connection.

Type code
Defines the function and format of each B-ISDN user part message. Examples of messages are: Address complete, Call progress, Forward transfer, and Release complete.

Message length
Number of octets in the message.

Compatibility
Message compatibility information. Defines the behavior of a switch if a message is not understood.

Message
Contents of the message.

Q.2140

Q.2140 is part of the ATM adaptation layer which supports signalling at the Network Node Interface of the B-ISDN. This protocol implements the Service Specific Coordination Function (SSCF) for signalling at the NNI.

The structure of the Q.2140 header is shown in the following illustration. The Q.2140 contains one field called SSCF status.

Reserved

SSCF Status

3 bytes

1 byte

Q.2140 header structure

The SSCF status indicates the status of the sending peer. It can have the following values:

0000 0001 Out of service
0000 0010 Processor Outage
0000 0011 In Service
0000 0100 Normal
0000 0101 Emergency
0000 0111 Alignment Not Successful
0000 1000 Management Initiated
0000 1001 Protocol Error
0000 1010 Proving Not successful

 

SPANS

SPANS (Simple Protocol for ATM Network Signalling) is a simple signalling protocol, developed by FORE systems and used by FORE and other manufacturers working in cooperation with FORE, for use in ATM networks.

The first part of this protocol is SPANS UNI which is used in ATM LANs. The protocol specifies the signalling messages that are exchanged between hosts and the ATM network to perform several functions such as opening and closing connections. These functions allow hosts and routers to use an ATM LAN as a subnet of a larger internet. The two classes of messages involved in this protocol are status messages and connection messages.

The second part of the protocol is SPANS NNI, which is a simple signalling protocol for routing and virtual path support in ATM LANs. This part of the protocol specifies the signalling messages that are exchanged between ATM network switches to perform functions such as opening and closing virtual paths. An ATM network switch is a device which is capable of forwarding data over ATM connections from one or more sources to one or more destinations. The two classes of messages involved with this protocol are topology messages and network internal connection messages.

Message Types

The types of messages, in more detail, are as follows:

  • STATUS messages, which transfer information about the state of a signalling peer. The status messages are as follows:
    Indications - Issued by the network.
    Responses - Issued in response to the network’s indications.
    Requests - Issued by hosts when booting.
  • CONNECTION messages are used in order to open new connections or close existing ones. The connection messages are as follows:
    Requests - The originating side, either the source or the destination of the connection, sends a request message.
    Indications - In most cases, the request causes an indication message to be issued by the network to the target host.
    Responses - The target host then returns a response message, in response to the request which was received.
    Confirmations - Finally, the network issues a confirmation message to the original source.
  • TOPOLOGY messages are exchanged between switches within a network. Through these messages, switches learn of changes in network topology, e.g., new switches coming on line, switches and links going down, and changing node and link loads.
  • NETWORK-INTERNAL CONNECTION messages are exchanged by switches in the network to set up and manage virtual paths. The originating switch issues a request, which may be forwarded as a request by intermediate switches until it reaches the target switch. The target switch produces a reply, which again may be forwarded by intermediate switches on its way back to the originator.

Specifications

SPANS signalling messages are transferred over a reserved ATM virtual connection, using AAL type 3/4. Currently this connection uses VPI 0 and VCI 15. This channel must be predefined in both directions, on all links used by participants in the signalling protocol.

A null transport layer is used. Retransmission of lost messages and suppression of duplicate messages are performed by the application when necessary.

 

ViVID MPOA

ViVID is a proprietary protocol of Newbridge which provides bridged LAN Emulation. and routed LAN Emulation functionality. There are 3 protocols in the ViVID group, BME, ARM and CCP. They share a common header format. All ViVID protocols are LLC/SNAP encapsulated. The Newbridge OUI and a PID value of 0x02 identify them as ViVID.

 

MPOA

The Multi Protocol Over ATM (MPOA) deals with the efficient transfer of inter-subnet unicast data in a LANE environment. MPOA integrates LANE and NHRP to preserve the benefits of LAN Emulation, while allowing inter-subnet, internetwork layer protocol communication over ATM VCCs without requiring routers in the data path. MPOA provides a framework for effectively synthesizing bridging and routing with ATM in an environment of diverse protocols, network technologies, and IEEE 802.1 virtual LANs. MPOA is capable of using both routing and bridging information to locate the optimal exit from the ATM cloud.
(Compliant with the ATM Forum Specification STR-MPOA-MPOA-01.00 04-1997.)

The format of the header is shown in the following illustration:

8

16

24

32

bits

ar$afn

ar$pro.type

ar$pro.snap

ar$pro.snap

ar$hopcnt

ar$pkstz

ar$chksum

ar$extoff

ar$op.version

ar$op.type

ar$shtl ar$sstl

MPOA header structure

ar$afn
Defines the type of "link layer" address being carried.

ar$pro.type
This field is a 16 bit unsigned integer.

ar$pro.snap
When ar$pro.type has a value of 0x0080, a snap encoded extension is being used to encode the protocol type. This snap extension is placed in the ar$pro.snap field; otherwise this field should be set to 0.

ar$hopcnt
The hop count. This indicates the maximum number of NHSs that an MPOA packet is allowed to traverse before being discarded.

ar$pktsz
The total length of the MPOA packet in octets.

ar$chksum
The standard IP checksum over the entire MPOA packet.

ar$extoff
This field identifies the existence and location of MPOA extensions.

ar$op.version
This field indicates what version of generic address mapping and management protocol is represented by this message.

ar$op.type
The MPOA packet type. Possible values for packet types are:

128 MPOA Cache Imposition Request.
129 MPOA Cache Imposition Reply.
130 MPOA Egress Cache Purge Request.
131 MPOA Egress Cache Purge Reply.
132 MPOA Keep-Alive.
133 MPOA Trigger.
134 MPOA Resolution Request.
135 MPOA Resolution Reply.
5 MPOA Data Plane Purge.
6 MPOA Purge Reply.
7 MPOA Error Indication.

ar$shtl
The type and length of the source NBMA address interpreted in the context of the "address family number".

ar$sstl
The type and length of the source NBMA subaddress interpreted in the context of the "address family number".


search ][ protocols by family ][ index of protocols