Technical Committee

PNNI addendum for mobility extensions version 1.0

AF-RA-0123.000

May, 1999

© 1999 by The ATM Forum.  This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution.  Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution.  All other rights reserved.  Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum.

The information in this publication is believed to be accurate as of its publication date.  Such information is subject to change without notice and The ATM Forum is not responsible for any errors.  The ATM Forum does not assume any responsibility to update or correct any information in this publication.  Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication.  No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication.

The receipt or any use of this document or its contents does not in any way create by implication or otherwise:

•	Any express or implied license or right to or under any ATM Forum member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor
•	Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such  announced product(s) and/or service(s) embody any or all of the ideas, technologies, or  concepts contained herein; nor
•	Any form of relationship between any ATM Forum member companies and the recipient or user of this document.

Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in The ATM Forum.

The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology.  The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.

NOTE:  The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others.  By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights.  ATM Forum Member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license.  For additional information contact:

The ATM Forum
Worldwide Headquarters
2570 West El Camino Real, Suite 304
Mountain View, CA 94040-1313
Tel:	+1-650-949-6700
Fax:	+1-650-949-6705

Acknowledgments
The Routing and Addressing working group was chaired by Mickey Spiegel. Laurent Freléchoux was the editor for the PNNI addendum for mobility extensions specification. The minutes at related working group meetings were recorded by Tim Dwight.
The following people made significant technical contributions to the PNNI addendum for mobility extensions specification:
David Cypher	
Tim Dwight	
Doug Dykeman	
Laurent Freléchoux	
Joel Halpern	
Sankar Ray	
Mickey Spiegel	

	

	

Table of contents
1.	Mobility extensions routing description	5
1.1	Mobile network, mobile switch, access point switch and mobile link	6
1.2	Mobile logical group node	6
1.3	Use of the mobility extensions	6
1.4	Structure of the network	6
2.	Mobility extensions routing specification	9
2.1	General information	9
2.1.1	Scope	9
2.1.2	Compatibility with PNNI v1.0	9
2.2	Mobile network to fixed network routing	9
2.2.1	Advertising outside nodal hierarchy lists	9
2.2.2	Advertising partial nodal hierarchy list	12
3.	Changes to existing sections of PNNI v1.0 specifications	13
3.1	The Nodal Information	13
3.2	The Nodal Hierarchy List IG	13
3.3	The Nodal Information Group	13
3.4	Information group Summary	13
4.	References	14
Annex A.	Mobility extensions SNMP MIB	15
Annex B.	Mobility extensions PICS proforma	26
B.1	Introduction	26
B.1.1	Scope	26
B.1.2	Normative References	26
B.1.3	Definitions	26
B.1.4	Acronyms	26
B.1.5	Conformance	27
B.2	Identification of the Implementation	28
B.3	PICS Proforma	31
B.3.1	Global statement of conformance	31
B.3.2	Instructions for Completing the PICS Proforma	31
B.4	Roles	32
B.5	Additional specifications implemented to support the mobility extensions	32
B.6	General mobile switch	32
B.7	Border node mobile switch	33
B.8	Peer group leader / logical group node mobile switch	34
B.9	Border node access point switch	36

Table of figures
Figure 1: Mobile network changing access point switch	5
Figure 2: Structure of a network	8

PNNI addendum for mobility extensions
This addendum to ATM Forum PNNI v1.0 “Private Network-Network Interface Specification Version 1.0” [1] and ATM Forum PNNI v1.0 Errata and PICS [2] contains the description and specification of the routing extensions to support mobile switches and mobile networks.
Section one gives an overview of the routing extensions to support mobile switches and mobile networks. Section two contains the detailed specification of the mobility extensions. Section three lists the changes to the existing sections and sub-sections of PNNI v1.0 specification to support the mobility extensions. Annex A contains the SNMP MIB to manage the mobility extensions and annex B contains the PICS Proforma to report the capabilities of the implementation.
1.	Mobility extensions routing description
The network architecture addressed by these extensions is a mobile ATM network (referred to as a mobile network), consisting of one or more ATM switches, linked by one or more wireless connections to a fixed ATM internetworking infrastructure (referred to as a fixed network). These extensions cover neither the routing in ad-hoc mobile networks, nor the mobility of end-systems.
The mobility extensions allow a mobile network to join in the PNNI routing hierarchy of a fixed network, based on the point(s) at which the two networks are currently attached. Unlike fixed PNNI nodes, the attachment point(s) of a mobile network change over time. These extensions allow a mobile network to cross the boundary between two peer groups, by dynamically changing its membership to a peer group of the fixed network (see Figure 1). In this way it is possible to route from end-systems in a mobile network to the fixed network and vice versa, and by transitivity between the end-systems of two mobile networks. 
Connection hand-over is not addressed by these extensions. If a mobile network loses connectivity to an access point switch, all connections between the networks will have to be reestablished either by the end-systems or by any other automatic mechanism provided by the networks.

Figure 1: Mobile network changing access point switch
1.1	Mobile network, mobile switch, access point switch and mobile link
In this document, the term mobile network refers to a mobile group of switches that do not move relative to each other. The switches of a mobile network can be linked between themselves through either wired or wireless media.
The definition of a mobile switch is a switching system that is capable of the mobility extensions and has been configured as being mobile. A mobile network must contain one or more mobile switches.
An access point switch is a switching system belonging to the fixed network which has the capacity to establish a wireless link with a mobile switch.
A mobile link is a link between a mobile switch and an access point switch. The attachment ports of a mobile link must be configured as mobility enabled ports. A mobile link may be either a physical link or a virtual path connection.
A fixed network is composed of one or more non-mobile switches.
1.2	Mobile logical group node
The case of a mobile network that moves within the access point switches of a given peer group can already be handled with PNNI v1.0 routing. This solution is however not scalable to either a large number of mobile networks or a large number of access point switches.
The mobility extensions allow each mobile network to build its own PNNI hierarchy and integrate into the hierarchy of the fixed network in the form of a mobile logical group node. A mobile logical group node has the capability to dynamically change its membership from one peer group to another as it moves in space and time. A mobile logical group node is only allowed to join a parent peer group of one of its current access point switches.
A border node of the mobile network may have one or more active mobile outside links to one or more  access point switches. The border node uses one of the nodal hierarchy lists received from the access point switches to build an outside nodal hierarchy list that contains a list of the host peer groups available at the access point switch. An outside nodal hierarchy list is then flooded by the source border node within the peer group and eventually reaches the peer group leader. In each peer group, and at all levels of the hierarchy of the mobile network, the peer group leader is responsible for choosing one outside nodal hierarchy list out of the several that have been advertised by the nodes of its peer group. The chosen outside nodal hierarchy list is then flooded at the next level of hierarchy by the associated logical group node. The final decision as to which host peer group to join, is made by the peer group leader of the highest level peer group in the given mobile network, the node that instantiates the mobile logical group node.
1.3	Use of the mobility extensions
Only the border nodes that have a mobile link attached, and the switches that are peer group leaders/logical group nodes in the mobile network have to be capable of the mobility extensions.
Routing support for mobility is designed for environments where changes of access point switches are infrequent. A change of access point switch has impact on both the mobile network and the fixed network. It is recommended that both networks normally have time to complete the transition before the mobile network decides to change to the next access point switch.
1.4	Structure of the network
The network is divided into three types of components: the mobile networks, the access point providers, and the rest of the fixed network (see Figure 2). A mobile network integrates into the hierarchy of the network of an access point provider as a single logical group node. The network of the access point provider, in turn, integrates into the rest of the fixed network as a single logical group node. It is recommended that the access point provider advertise only summarized reachability information into the rest of the fixed network. The reachability information that must be summarized includes the addresses of the access point's infrastructure and all the addresses of the mobile networks that joined the provider's hierarchy. 
To achieve the summarization of the reachability information, each access point provider should obtain a contiguous range of addresses. Each access point provider is then in charge of assigning sub-ranges to the mobile networks that use its services.
This structure and these summarization rules must be followed to ensure scalability in terms of the number of nodes and address prefixes in the ATM network. Poor summarization of reachability information results in an increase in the size of the PNNI topology database, and possible failure of nodes in the network.
Section 2.2.2 defines a protection mechanism to prevent mobile networks from joining at undesirable levels of the hierarchy. It is recommended that an access point provider use this mechanism to protect the fixed network against misconfigured mobile networks.

Figure 2: Structure of a network
2.	
Mobility extensions routing specification
The network architecture addressed by these extensions is a mobile wireless ATM network (referred to as a mobile network) linked by the means of one or several wireless connections to a fixed ATM internetworking infrastructure (referred to as a fixed network). 
2.1	General information
2.1.1	Scope
The mobility extensions are an optional feature of PNNI v1.0 [1,2]. 
In a mobile network, only border nodes that are attached to a mobile link and peer group leaders/logical group nodes need to support the PNNI mobility extensions. The other nodes of a mobile network and the nodes of the fixed network can run PNNI v1.0 without the mobility extensions.
Access point switches should be enhanced with the protection mechanism described in section 2.2.2.
2.1.2	Compatibility with PNNI v1.0
The mobility extensions are backward compatible with PNNI v1.0 [1,2]. 
The case where a border node or a peer group leader in the mobile network is not capable of the mobility extensions, has no impact on the network other than the fact that the mobile network may not be able to integrate into the hierarchy of the fixed network.
2.2	Mobile network to fixed network routing
A mobile network can join a fixed network as a single logical group node. This logical group node is referred to as a mobile logical group node.
The decision to join another network is taken by the peer group leader at the highest level of the mobile network. A peer group leader knows that it is at the highest level of the mobile network when it is elected PGL and its parent LGN is configured as a mobile LGN. To join another network, the peer group leader shall change its next higher level binding information based on the level and the peer group ID of the targeted host peer group. The peer group leader chooses which host peer group its parent logical group node will join, by selecting a level and a PGID from one of the outside nodal hierarchy lists that have been advertised inside its peer group. To be a candidate for selection, an outside nodal hierarchy list must have been issued by a node to which the peer group leader currently has connectivity. The peer group leader shall only select a level of the outside nodal hierarchy list that is higher than its own level, which is the highest level among the internal pre-configured nodes. Note that an implementation may wish to provide more detailed filters regarding which peer groups or at which levels a mobile LGN may join (i.e. configuration of a maximum level).
When integrating into the hierarchy of a fixed network, a mobile logical group node must not become the peer group leader of the host peer group it joins. Therefore a mobile logical group node shall advertise a leadership priority set to zero.

2.2.1	Advertising outside nodal hierarchy lists
The prerequisite for a switch to advertise an outside nodal hierarchy list is to be configured as a mobile switch.
In a mobile network, only border nodes and logical group nodes can advertise outside nodal hierarchy lists. A node can advertise one and only one outside nodal hierarchy list. All the nodes within a mobile network that are not peer group leaders shall ignore the advertised outside nodal hierarchy list.
Note that a mobile switch can be at the same time a border node and/or peer group leader at several levels of the hierarchy. In this case, each internal node of the switch executes its own decision process (i.e. chooses which outside nodal hierarchy list to advertise).
When sending the first instance of the outside nodal hierarchy list in the Nodal Information PTSE of a border node or peer group leader, the value of the sequence number must be greater than zero. Whenever a change occurs in the number or content of known higher levels, as expressed in the outside nodal hierarchy list, the sequence number of the outside nodal hierarchy list must be incremented, and a new Nodal Information PTSE must be originated subject to normal hold-down rules.
When a node in a mobile switch receives a nodal information PTSE instance that:
•	is more recent than its database copy, and
•	the Originating Node ID of the PTSE is listed as the receiving node itself, and
•	the PTSE contains an outside nodal hierarchy list information group, and
•	the sequence number of the outside nodal hierarchy list information group is equal or higher to the database copy of the outside nodal hierarchy list information group
then the node when reoriginating the nodal information PTSE, as described in section 5.8.3.3 (6)(a)(i) of PNNI version 1.0 specifications, must originate an outside nodal hierarchy list information group with a sequence number one higher than the sequence number in the outside nodal hierarchy list of the received PTSE.

2.2.1.1	Advertising outside nodal hierarchy lists from border nodes
A border node configured as a mobile switch in a mobile network can have more than one mobile link attached to it, and therefore be connected to more than one access point switch at a time.
A border node must start a new decision process for the advertisement of an outside nodal hierarchy list when:
•	the state of the Hello protocol of a mobile link changes to “Common Outside” or “2-Way Outside”.
•	the state of the Hello protocol of a mobile link leaves the state “Common Outside” or “2-Way Outside”.
The input of the decision process is a set of nodal hierarchy lists. This set contains each nodal hierarchy list that has been learned through the Hello packets of the different mobile links. To be a candidate to the decision process a nodal hierarchy list must have been issued by a neighbor node with which the border node has a mobile link in the state “2-Way Outside” or “Common Outside”.
The output of the decision process is none or one of the nodal hierarchy lists that were candidates.
If the output is one nodal hierarchy list, the border node sets the outside nodal hierarchy list of its nodal information group to the value of the selected nodal hierarchy list.
If the output is none, the border node removes any outside nodal hierarchy list from its nodal information group.
Upon completion of the decision process, a border node must re-originate a Nodal Information PTSE if the content of the nodal information group has been modified. This step is subject to the normal PNNI hold down requirements.
2.2.1.2	Handling outside nodal hierarchy lists in peer group leaders
A peer group leader belonging to a mobile network must start a new decision process for the selection of an outside nodal hierarchy list when it:
•	receives a more recent outside nodal hierarchy list from any node of its peer group, or
•	loses connectivity to any of the nodes in its peer group.
The input of the decision process is a set of outside nodal hierarchy lists. This set contains all the outside nodal hierarchy lists that have been advertised through the nodal information groups. To be a candidate to the decision process an outside nodal hierarchy list must have been issued by a node to which the peer group leader currently has connectivity.
The output of the decision process is none or one of the outside nodal hierarchy lists that were candidates. If there is another level of hierarchy above this peer group leader in the mobile network (i.e. excluding the level in which the mobile logical group node has joined the fixed network), it passes to its associated logical group node the output of the decision process.
An outside nodal hierarchy list contained in a received Nodal Information PTSE is more recent than the current database copy if:
•	the received Nodal Information PTSE is more recent than the Nodal Information PTSE contained in the database copy, as defined in section 5.8.2.2.4 of PNNI version 1.0 specifications, and
•	the sequence number of the received outside nodal hierarchy list is not equal to the sequence number of the current copy of the outside nodal hierarchy list information group.

2.2.1.3	Advertising outside nodal hierarchy lists from logical group nodes
A logical group node receives the output of the decision process from its associated lower level peer group leader. If the output is one outside nodal hierarchy list, the logical group node sets the outside nodal hierarchy list of its nodal information group to the value of the selected outside nodal hierarchy list.
If the output is none, the logical group node removes any outside nodal hierarchy list from its nodal information group.
Upon completion of the decision process, a logical group node must re-originate a Nodal Information PTSE if the content of the nodal information group has been modified. This step is subject to the normal PNNI hold down requirements.
2.2.1.4	Decision process
The algorithm that implements the decision process is implementation dependent. Nevertheless, the first concern of the algorithm should be to ensure stability in the network. It is therefore strongly recommended that the algorithm favors an outside nodal hierarchy list that can maintain the presence of the mobile network in the current host peer group.
2.2.2	Advertising partial nodal hierarchy list
To prevent mobile networks from joining at undesirable levels of the hierarchy, an access point switch is allowed to advertise partial nodal hierarchy lists in the Hello protocol of its attached mobile links.
This procedure is not a security mechanism but a protection mechanism against misconfigured mobile networks. The use of partial nodal hierarchy lists is restricted to the Hello protocol of mobile links.
A partial nodal hierarchy list is defined as the n-lower hierarchy levels of a complete nodal hierarchy list. A partial nodal hierarchy list is syntactically identical to a nodal hierarchy list, and there is no means to differentiate a partial nodal hierarchy list from a complete nodal hierarchy list. Each access point switch chooses the number n of levels to be contained in the partial nodal hierarchy lists it advertises. An access point switch can advertise different partial nodal hierarchy lists on the different mobile links attached, meaning that the highest level contained in the partial nodal hierarchy lists may be different for each mobile link.
It is strongly recommended that an access point provider uses this protection mechanism in the Hello protocol of all attached mobile links. The advertised partial nodal hierarchy lists should only contain levels of the hierarchy that are lower than the level at which the summarization of reachability information must occur (see section 1.4).
3.	
Changes to existing sections of PNNI v1.0 specifications
The outside nodal hierarchy list information group is added to PNNI v1.0 specification as described in the following sections.
3.1	The Nodal Information
The following additional item is appended to the list of section 5.8.1.2 of PNNI v1.0 specifications:
•	outside nodal hierarchy list (may be included if this node belongs to a mobile network and is either a border node or a logical group node)
3.2	The Nodal Hierarchy List IG
The following text is added as a second paragraph to section 5.14.8.2 of PNNI v1.0 specifications:
The outside nodal hierarchy list is included in nodal information group PTSEs in order to allow a border node to communicate to its higher level nodes information about the higher level peer groups of its outside neighbor nodes, and to allow logical group nodes to forward this information to higher level nodes. The content of this information is the same as described for the nodal hierarchy list in the above paragraph. The outside nodal hierarchy list is used for mobility support, as described in section 2. The information group tags of the outside nodal hierarchy list information group shall be set to optional, summarizable and non-transitive.
The following new type value is added to the Table 5-29 of PNNI v1.0 specifications:
Type = 36 (outside nodal hierarchy list)
3.3	The Nodal Information Group
The following text is added at the bottom of Table 5-35 of PNNI v1.0 specifications:
Outside Nodal Hierarchy List:
(may be sent by a border node or a logical group node that belongs to a mobile network)
Outside Nodal Hierarchy List Information Group (type=36)
see section 5.14.8.2
3.4	Information group Summary
The following existing row is modified in Table 5-18 of PNNI v1.0 specifications:
Table 5-18 Information Group Summary
Type	IG Name	Contains IGs one level down	
97	Nodal information group	Next higher level binding information (192), Outside nodal hierarchy list (36)	

The following additional row is inserted into Table 5-18 (continued) of PNNI v1.0 specifications:
Table 5-18 Information Group Summary continued
Type	IG Name	Contains IGs one level up	Contained in packets	
36	Outside nodal hierarchy list 	Nodal information group (97)	PTSP (2)	

The following existing row is modified in Table 5-19 of PNNI v1.0 specifications:
Table 5-19 Information Groups in PNNI Packets
Type	Packet Name	Contains IGs	
2	PTSP	PTSE (64), Nodal state parameters (96), Nodal information group (97), Outgoing resource availability (128), Incoming resource availability (129), Next higher level binding information (192), Optional GCAC parameters (160), Internal reachable ATM addresses (224), Exterior reachable ATM addresses (256), Horizontal links (288), Uplinks (289), Transit network ID (304), System capabilities (640), Outside nodal hierarchy list (36)	

1.	References

[1]	Private Network-Network Interface Specification Version 1.0, ATM Forum af-pnni-0055.000, March 1996
[2]	PNNI v1.0 Errata and PICS, ATM Forum af-pnni-0081.000, May 1997

Annex A.	Mobility extensions SNMP MIB

PNNI-MOB-EXT-MIB DEFINITIONS ::= BEGIN
        IMPORTS                MODULE-IDENTITY, OBJECT-TYPE,
                Counter32, Integer32, enterprises                        FROM SNMPv2-SMI
                TEXTUAL-CONVENTION,
                TimeStamp, TruthValue
                        FROM SNMPv2-TC
                InterfaceIndex
                        FROM IF-MIB
                PnniNodeId, PnniAtmAddr, PnniPeerGroupId,
                pnniNodeIndex, PnniNodeIndex, PnniLevel,
                pnniNodeEntry, pnniIfEntry
                        FROM PNNI-MIB
                MODULE-COMPLIANCE, OBJECT-GROUP
                        FROM SNMPv2-CONF;

pnniMobExtMIB MODULE-IDENTITY
        LAST-UPDATED    "9902120000Z"
        ORGANIZATION    "The ATM Forum"
        CONTACT-INFO
            "The ATM Forum
             2570 West El Camino Real, Suite 304
             Mountain View, CA 94040-1313 USA
             Phone: +1 415-949-6700
             Fax:   +1 415-949-6705
             info@atmforum.com"
        DESCRIPTION
            "The MIB module for managing the ATM Forum extensions of 
             PNNI routing for mobile networks."
       REVISION "9902120000Z"
       DESCRIPTION
          "Initial version of the MIB module for managing PNNI routing
           extensions for the support of mobile networks."
        ::= { atmfPnni 2 }

-- The object identifier subtree for the ATM Forum mobility extensions PNNI MIBs

atmForum        OBJECT IDENTIFIER ::= { enterprises 353 }
atmForumNetworkManagement       OBJECT IDENTIFIER ::= { atmForum 5 }
atmfPnni        OBJECT IDENTIFIER ::= { atmForumNetworkManagement 4 }

pnniMobExtMIBObjects OBJECT IDENTIFIER ::= { pnniMobExtMIB 1 }

    PnniOnhlIndex ::= TEXTUAL-CONVENTION
        STATUS        current
        DESCRIPTION
            "An index that identifies an outside nodal hierarchy list
             in the managed mobile system.

             The distinguished value zero indicates the null instance 
             or no instance."
        SYNTAX        Integer32 (0..65535)

-- This MIB is divided in two main groups of objects :
--
--    Objects needed for the management of a mobile switching system
--    Objects needed for the management of an access point switching system
--
-- The pnniMobExtBaseGroup contains objects for the general management 
-- of the mobility extensions.
-- 

-- The pnniMobileSwitchGroup contains objects needed for the management of
-- a mobile switching system.
-- Content : - Table of mobility enabled PNNI interfaces 
--           - Mobile logical group node
--           - Table of outside nodal hierarchy list
--           - Table of decision process information per node
--           - Table of input onhl per node
--
-- The pnniAccessPointGroup contains objects needed for the management of
-- an access point switching system.
-- Content : - Table of partial NHL filter for PNNI interfaces
--

--
-- Group: pnniMobExtBaseGroup
-- 
pnniMobExtBaseGroup OBJECT IDENTIFIER ::= { pnniMobExtMIBObjects 1 }

pnniMobExtVersion OBJECT-TYPE
        SYNTAX        INTEGER {unsupported (1), version1point0 (2)}
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The version of the PNNI Addendum for mobility extensions 
            that the software in this switching system is capable of 
            executing."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.1"
        ::= { pnniMobExtBaseGroup 1 }

--
-- Mobile Switch Group: pnniMobileSwitchGroup
-- 

pnniMobileSwitchGroup OBJECT IDENTIFIER ::= { pnniMobExtMIBObjects 2 }

-- Mobility enabled interface table

pnniMSMobileIfTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF PnniMSMobileIfEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "Contains the attributes necessary to configure PNNI interfaces on 
             a mobile switching system"
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 1.1"
        ::= { pnniMobileSwitchGroup 1 }

pnniMSMobileIfEntry OBJECT-TYPE
        SYNTAX        PnniMSMobileIfEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "Contains the attributes necessary to configure PNNI interfaces 
             on a mobile switching system "
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 1.1"
        AUGMENTS { pnniIfEntry }
        ::= { pnniMSMobileIfTable 1 }

PnniMSMobileIfEntry ::=
        SEQUENCE {
                  pnniIfMobilityEnabled     TruthValue
                 }

pnniIfMobilityEnabled OBJECT-TYPE
        SYNTAX        TruthValue
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
            "Indicates whether this interface is configured as a PNNI mobility 
             enabled interface or not. When the interface is configured as 
             mobility enabled, the mobile switch considers the nodal hierarchy
             list received from this interface as a candidate for the decision
             process."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 1.1"
        DEFVAL { false } 
        ::= { pnniMSMobileIfEntry 1 }

-- Mobile logical group node 

pnniMSMobileLgnGroup OBJECT IDENTIFIER ::= { pnniMobileSwitchGroup 2 }

pnniMobileLgnIndex OBJECT-TYPE
        SYNTAX        PnniNodeIndex
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
            "Indicates the node index of the mobile logical group
             node on this switching system. The mobile logical
             group node can be either active, or yet to become operational.
             This attribute contains always the index to an entry in
             the pnniNodeTable.

             The distinguished value zero indicates the null instance or 
             no instance in the pnniMobileLgnIndex. It indicates that no
             mobile logical group node has been configured on this
             switching system.

             The mobile logical node cannot be the lowest level node in the 
             switching system.

             This object must reference the highest configured node (i.e.
             the highest level node that can become operational). 

             If the node has a value of 'up' for its pnniOperStatus, the 
             pnniPeerGroupId and pnniNodeLevel have relevant values,
             that must be considered as READ-ONLY. 

             If the node has a value of 'down' for its pnniOperStatus, the 
             values of pnniPeerGroupId and pnniNodeLevel are not relevant."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSMobileLgnGroup 1 }

pnniMobileLgnMinLevel OBJECT-TYPE
        SYNTAX        PnniLevel
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "This value indicates the lowest level at which the
             mobile logical group node can join a host peer group.

             This value is read-only to reflect that it is dependent
             on the configuration of the local nodes in this switching 
             system. The value is equal to the value of the level
             indicator of the child node of this mobile logical
             group node minus 1."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSMobileLgnGroup 2 }

pnniMobileLgnMaxLevel OBJECT-TYPE
        SYNTAX        PnniLevel
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
            "This value indicates the highest level at which the
             mobile logical group node is allowed to join a host
             peer group.

             If the value of this attribute is larger (i.e. the 
             level is lower) than the value of pnniMobileLgnMinLevel, 
             the mobile logical group node is not able to join any 
             host peer group."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSMobileLgnGroup 3 }

-- Mobile switch : outside nodal hierarchy list table

pnniMSOnhlTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF PnniMSOnhlEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "A table of the outside nodal hierarchy lists present 
             in this switching system."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMobileSwitchGroup 3 }

pnniMSOnhlEntry OBJECT-TYPE
        SYNTAX        PnniMSOnhlEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "An entry in this table that contains attributes 
             describing one level of an outside nodal hierarchy list"
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        INDEX { pnniOnhlIndex, pnniOnhlLevel } 
        ::= { pnniMSOnhlTable 1 }

PnniMSOnhlEntry ::=
        SEQUENCE {
                  pnniOnhlIndex                  PnniOnhlIndex,
                  pnniOnhlLevel                  PnniLevel,
                  pnniOnhlPeerGroupId            PnniPeerGroupId,
                  pnniOnhlNodeId                 PnniNodeId,
                  pnniOnhlAtmAddr                PnniAtmAddr
                 }

pnniOnhlIndex OBJECT-TYPE
        SYNTAX        PnniOnhlIndex
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "A value assigned to an outside nodal hierarchy list 
             in this switching system that uniquely identifies it 
             in the MIB."
        ::= { pnniMSOnhlEntry 1 }

pnniOnhlLevel OBJECT-TYPE
        SYNTAX        PnniLevel
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "A level included in this outside nodal hierarchy list."
        ::= { pnniMSOnhlEntry 2 }

pnniOnhlPeerGroupId OBJECT-TYPE
        SYNTAX        PnniPeerGroupId
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The peer group id advertised by another switching system
             at this level of its nodal hierarchy list."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 3.2"
        ::= { pnniMSOnhlEntry 3 }

pnniOnhlNodeId OBJECT-TYPE
        SYNTAX        PnniNodeId
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The node id advertised by another switching system
             at this level of its nodal hierarchy list."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 3.2"
        ::= { pnniMSOnhlEntry 4 }

pnniOnhlAtmAddr OBJECT-TYPE
        SYNTAX        PnniAtmAddr
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The atm address advertised by another switching system
             at this level of its nodal hierarchy list."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 3.2"
        ::= { pnniMSOnhlEntry 5 }

-- mobile switch : node table

pnniMSNodeTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF PnniMSNodeEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "The pnniMSNodeTable collects attributes that affect 
             the decision process executed by each node local to
             this switching system.

             This table is an augmentation of the pnniNodeTable."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2"
        ::= { pnniMobileSwitchGroup 4 }

pnniMSNodeEntry OBJECT-TYPE
        SYNTAX        PnniMSNodeEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "An entry in the table, containing information about 
             the decision process associated to the logical node
             in this switching system"
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2"
        AUGMENTS { pnniNodeEntry }
        ::= { pnniMSNodeTable 1 }

PnniMSNodeEntry ::=
        SEQUENCE {
               pnniOutputOnhlIndex               PnniOnhlIndex,
               pnniOutputOnhlTimeStamp           TimeStamp,
               pnniDecisionProcessTimeStamp      TimeStamp,
               pnniDecisionProcessCount          Counter32
                 }

pnniOutputOnhlIndex OBJECT-TYPE
        SYNTAX        PnniOnhlIndex
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "Indicates the local index in the pnniMSOnhlTable of 
             the outside nodal hierarchy list resulting from the 
             last decision process.

             If the decision process has never run, or if no
             outside nodal hierarchy list was chosen, this
             attribute is set to the null value (0)"
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSNodeEntry 1 }

pnniOutputOnhlTimeStamp OBJECT-TYPE
        SYNTAX        TimeStamp
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "Indicates the time at which the current outside 
             nodal hierarchy list resulting from the decision
             process was selected as output onhl.

             This time is not reset each time that the
             pnniDecisionProcessTimeStamp is reset. The condition
             for a reset is that the outside nodal hierarchy list 
             resulting from the decision process is different from
             the previous one."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSNodeEntry 2 }

pnniDecisionProcessTimeStamp OBJECT-TYPE
        SYNTAX        TimeStamp
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "Indicates the last time that the decision process
             was executed by this node."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSNodeEntry 3 }

pnniDecisionProcessCount OBJECT-TYPE
        SYNTAX        Counter32
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The number of times that the decision process has
             been executed by this node."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSNodeEntry 4 }

-- mobile switch : input outside nodal hierarchy list table

pnniMSInputOnhlTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF PnniMSInputOnhlEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "The pnniMSInputOnhlTable collects attributes
             on a per node basis for each outside nodal hierarchy list 
             that is an input to the decision process."
         REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMobileSwitchGroup 5 }

pnniMSInputOnhlEntry OBJECT-TYPE
        SYNTAX        PnniMSInputOnhlEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "An entry to the table containing attributes 
             about an outside nodal hierarchy list which
             belongs to the input pool of a decision process.

             Only outside nodal hierarchy lists that are valid
             candidates for the decision process are part of the
             input pool."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        INDEX { pnniNodeIndex, pnniOnhlIndex } 
        ::= { pnniMSInputOnhlTable 1 }

PnniMSInputOnhlEntry ::=
        SEQUENCE {
                  pnniInputOnhlTimeStamp         TimeStamp,
                  pnniInputOnhlSourceType        INTEGER,
                  pnniInputOnhlNodeIdSource      PnniNodeId,
                  pnniInputOnhlMobileIfSource    InterfaceIndex,
                  pnniInputOnhlNodeIndexSource   PnniNodeIndex
                 }

pnniInputOnhlTimeStamp OBJECT-TYPE
        SYNTAX        TimeStamp
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "Indicates the time at which the outside nodal hierarchy
             list was inserted into the input pool of this nodal decision
             process."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSInputOnhlEntry 1 }

pnniInputOnhlSourceType OBJECT-TYPE
        SYNTAX        INTEGER { undefined(0), 
                                mobileInterface(1), 
                                nodalInformationGroup(2),
                                localNode(3)
                               }
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The type of the source that originated the outside nodal 
             hierarchy list.

             If the outside nodal hierarchy list is a copy of a nodal
             hierarchy list received from a mobile interface,
             this attribute contains the value 'mobileInterface'.

             If the outside nodal hierarchy list was extracted from a 
             nodal information group of an external node (i.e. not on
             this switching system), this attribute contains the 
             value 'nodalInformationGroup'.

             If the outside nodal hierarchy list is passed from a child
             node (i.e on the same switching system), this attribute
             contains the value 'localNode'."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSInputOnhlEntry 2 }

pnniInputOnhlNodeIdSource OBJECT-TYPE
        SYNTAX        PnniNodeId
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The node id of the node which was the source of this outside
             nodal hierarchy list.

             If pnniInputOnhlSourceType has a value of 'mobileInterface',
             this attribute contains the node id of the border node that
             advertised the nodal hierarchy list.

             If pnniInputOnhlSourceType has a value of 'nodalInformationGroup' ,
             this attribute contains the node id of the node that generated 
             the nodal information group.

             If pnniInputOnhlSourceType has a value of 'localNode',
             inside of the switching system, this attribute contains the 
             node id of the local node.

             If pnniInputOnhlSourceType has none of the above mentioned values, 
             this attribute has a value of 0."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSInputOnhlEntry 3 }

pnniInputOnhlMobileIfSource OBJECT-TYPE
        SYNTAX        InterfaceIndex
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "If pnniInputOnhlSourceType has the value of 'mobileInterface',
             this attributes contains the index in the pnniIfTable of
             the mobile interface from which the outside nodal hierarchy
             list was generated.

             For all other values of pnniInputOnhlSourceType, this attribute 
             has a value of 0."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSInputOnhlEntry 4 }

pnniInputOnhlNodeIndexSource OBJECT-TYPE
        SYNTAX        PnniNodeIndex
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "If pnniInputOnhlSourceType has the value of 'localNode',
             this attribute contains the index in the pnniNodeTable of
             the child node that selected this outside nodal hierarchy 
             list as the output nodal hierarchy list.

             For all other values of pnniInputOnhlSourceType, this attribute 
             has a value of 0."
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2"
        ::= { pnniMSInputOnhlEntry 5 }

--
-- Access Point Group: pnniAccessPointGroup
-- 

pnniAccessPointGroup OBJECT IDENTIFIER ::= { pnniMobExtMIBObjects 3 }

-- access point : NHL filters for PNNI interfaces

pnniAPMobileIfTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF PnniAPMobileIfEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
             "Contains the attributes necessary to configure PNNI interfaces 
             on an access point switching system "
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2.2."
        ::= { pnniAccessPointGroup 1 }

pnniAPMobileIfEntry OBJECT-TYPE
        SYNTAX        PnniAPMobileIfEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            " Contains the attributes necessary to configure PNNI interfaces 
             on an access point switching system "
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2.2"
        AUGMENTS { pnniIfEntry }
        ::= { pnniAPMobileIfTable 1 }

PnniAPMobileIfEntry ::=
        SEQUENCE {
                  pnniAPMobileIfNhlLevelFilter      PnniLevel
                 }

pnniAPMobileIfNhlLevelFilter OBJECT-TYPE
        SYNTAX        PnniLevel
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
            "This attribute is used to apply a mask on the nodal hierarchy 
             list advertised in HELLO protocol on this specific 
             interface.

             The value of this attribute specifies the highest level 
             of the PNNI hierarchy advertised in the nodal hierarchy list.
             In other words, any entry of the nodal hierarchy list that 
             has a value for the level smaller than the value of this 
             attribute is not advertised.

             A value of zero indicates that no filter is applied"
        REFERENCE
            "ATM Forum PNNI Addendum for mobility extensions section 2.2.2"
        DEFVAL { 0 } 
        ::= { pnniAPMobileIfEntry 1 }

-- conformance information

pnniMobExtMIBConformance
                   OBJECT IDENTIFIER ::= { pnniMobExtMIB 2 }
pnniMobExtMIBCompliances
                   OBJECT IDENTIFIER ::= { pnniMobExtMIBConformance 1 }
pnniMobExtMIBGroups
                   OBJECT IDENTIFIER ::= { pnniMobExtMIBConformance 2 }

-- compliance statements

pnniMobExtMIBCompliance MODULE-COMPLIANCE
        STATUS        current
        DESCRIPTION
            "The compliance statement for entities which implement
             the PNNI mobility extensions MIB.

             Groups of the PNNI mobility extensions objects required
             for using these extensions are identified by the suffix MinGroup.

             Groups of PNNI mobile extensions objects required for management 
             of a mobile switch are identified by the suffix MSGroup.

             Groups of optional PNNI mobility extensions objects for 
             the management of an  access point switch are identified 
             by the suffix APOptionalGroup."

        MODULE  -- this module
            MANDATORY-GROUPS { 
                               pnniMobExtMinGroup
                              }

        ::= { pnniMobExtMIBCompliances 1 }

-- units of conformance

pnniMobExtMinGroup OBJECT-GROUP
        OBJECTS { 
                  pnniMobExtVersion

                  }
        STATUS current
        DESCRIPTION
            "A collection of mobility extensions objects required
             for using the extensions in a switching system."
        ::= { pnniMobExtMIBGroups 1 }

pnniIfMSGroup OBJECT-GROUP
        OBJECTS {
                   pnniIfMobilityEnabled
                 }
        STATUS current
        DESCRIPTION
            "A collection of per interface, mobility related PNNI mobility 
             extensions objects required for the management of mobile switch."
        ::= { pnniMobExtMIBGroups 2 }

pnniMobileLgnMSGroup OBJECT-GROUP
        OBJECTS {
                   pnniMobileLgnIndex,
                   pnniMobileLgnMinLevel,
                   pnniMobileLgnMaxLevel
                 }
        STATUS current
        DESCRIPTION
            "A collection of mobile LGN related PNNI mobility 
             extensions objects required for the management of 
             mobile switch."
        ::= { pnniMobExtMIBGroups 3 }

pnniOnhlMSGroup OBJECT-GROUP
        OBJECTS {
                   pnniOnhlNodeId,
                   pnniOnhlAtmAddr,
                   pnniOnhlPeerGroupId
                  }
        STATUS current
        DESCRIPTION
            "A collection of onhl related PNNI mobility extensions objects 
             required for the management of a mobile switch."
        ::= { pnniMobExtMIBGroups 4 }

pnniNodeMSGroup OBJECT-GROUP
        OBJECTS {
                  pnniOutputOnhlIndex,
                  pnniOutputOnhlTimeStamp,
                  pnniDecisionProcessTimeStamp,
                  pnniDecisionProcessCount
                 }
        STATUS current
        DESCRIPTION
            "A collection of per node decision process related PNNI 
             mobility extensions objects required for management of 
             a mobile switch."
        ::= { pnniMobExtMIBGroups 5 }

pnniInputOnhlMSGroup OBJECT-GROUP
        OBJECTS {
                  pnniInputOnhlTimeStamp,
                  pnniInputOnhlSourceType,
                  pnniInputOnhlNodeIdSource,
                  pnniInputOnhlMobileIfSource,
                  pnniInputOnhlNodeIndexSource
                  }
        STATUS current
        DESCRIPTION
            "A collection of per node input onhl related PNNI 
             mobility extensions objects required for the 
             management of a mobile switch."
        ::= { pnniMobExtMIBGroups 6 }

pnniMobileIfAPOptionalGroup OBJECT-GROUP
        OBJECTS {
                  pnniAPMobileIfNhlLevelFilter
                  }
        STATUS current
        DESCRIPTION
            "A collection of optional, per PNNI interface, NHL 
             filters related PNNI mobility extensions objects 
             for management of an access point switching system."
        ::= { pnniMobExtMIBGroups 7 }

END

Annex B.	Mobility extensions PICS proforma
.1	Introduction
To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options that have been implemented.  Such a statement is called a Protocol Implementation Conformance Statement (PICS).
.1.1	Scope
This document provides the PICS proforma for the PNNI addendum for mobility extensions version 1.0, as specified in this document in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2[2].  In most cases, statements contained in notes in the specification, which were intended as information, are not included in the PICS.
.1.2	Normative References
[1]	ISO/IEC 9646-1:1994, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 1: General Concepts. (See also ITU Recommendation X.290(1995)).
[2]	ISO/IEC 9646-2:1994, Information technology - Open systems interconnection - Conformance testing methodology and interconnection - Part 2: Abstract test suite specification. (See also ITU Recommendation X.291(1995)).
[3]	Private Network-Network Interface Specification Version 1.0, ATM Forum af-pnni-0055.000, March 1996
[4]	PNNI v1.0 Errata and PICS, ATM Forum af-pnni-0081.000, May 1997
.1.3	Definitions
This document uses the following terms defined in ISO/IEC 9646-1[1]:
•	A Protocol Implementation Conformance Statement (PICS) is a statement  made by the supplier of an implementation or system, stating which capabilities have been implemented for a given protocol.
•	A PICS proforma is a document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite specifier, which when completed for an implementation or system becomes the PICS.
.1.4	Acronyms
IG	Information Group	
IUT	Implementation Under Test	
M	Mandatory requirements (these are to be observed in all cases)	
NHL	Nodal hierarchy list	
O		Optional (may be selected to suit the implementation, provided that any requirements applicable to the options are observed)	
O.n	Optional, but support is required for either at least one or only one of the options in the group labeled with the same numeral "n".	
ONHL	Outside nodal hierarchy list	
PICS	Protocol Implementation Conformance Statement	
PTSE	PNNI Topology State Element	
.1.5	Conformance
The supplier of a protocol implementation which is claimed to conform to the ATM Forum PNNI addendum for mobility extensions version 1.0 is required to complete a copy of the PICS proforma provided in this document and is required to provide the information necessary to identify both the supplier and the implementation.
.2	
Identification of the Implementation
Implementation Under Test (IUT) Identification
IUT Name: ____________________________________________________________________
IUT Version: __________________________________________________________________
______________________________________________________________________________
System Under Test (SUT) Identification
SUT Name: ___________________________________________________________________
Hardware Configuration: _________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Operating System: ______________________________________________________________
Product Supplier
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________

Client
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _______________________________________________________________
Additional Information: __________________________________________________________
PICS Contact Person
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________
PICS/System Conformance Statement
Provide the relationship of the PICS with the System Conformance Statement for the system: 
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Identification of the protocol
This PICS proforma applies to the following:
* ATM Forum PNNI addendum for mobility extensions version 1.0.
.3	
PICS Proforma
.3.1	Global statement of conformance
The implementation described in this PICS meets all of the mandatory requirements of the reference protocol.

[ ] YES
[ ] NO

Note:   Answering "No" indicates non-conformance to the specified protocol.   Non-supported mandatory capabilities are to be identified in the following tables, with an explanation by the implementor explaining why the implementation is non-conforming.

.3.2	Instructions for Completing the PICS Proforma
The PICS Proforma is a fixed-format questionnaire.  Answers to the questionnaire should be provided in the rightmost columns, either by simply indicating a restricted choice (such as Yes or No), or by entering a value or a set of range of values.
A supplier may also provide additional information, categorized as exceptional or supplementary information.  These additional information should be provided as items labeled X.<i> for exceptional information, or S.<i> for supplemental information, respectively, for cross reference purposes, where <i> is any unambiguous identification for the item.  The exception and supplementary information are not mandatory and the PICS is complete without such information.  The presence of optional supplementary or exception information should not affect test execution, and will in no way affect interoperability verification.  The column labeled ‘Reference’ gives a pointer to sections of the protocol specification for which the PICS Proforma is being written.

.4	Roles
Item	Roles
Is the implementation of the PNNI addendum for  the mobility extensions capable of ...	Prerequisite	Status	Reference	Support	
Role1	Functioning as a mobile switch ?		M	1.1	[ ]Yes [ ]No	
Role1.1	Functioning as a mobile switch with border node capabilities ?	Role1,
SS_B (from PNNI v1.0 PICS)	O.1	1.2	[ ]Yes [ ]No	
Role1.2	Functioning as a mobile switch with peer group leader/ logical group node capabilities ?	Role1,
SS_P (from PNNI v1.0 PICS)	O.1	1.2	[ ]Yes [ ]No
	
Role2	Functioning as an access point switch with border node capabilities ?	SS_B (from PNNI v1.0 PICS)	O	1.1	[ ]Yes [ ]No
	
Comments:

Table 1: Roles

Note O.1: At least one of these roles must be supported

.5	Additional specifications implemented to support the mobility extensions
Item	Additional Specifications Supported
Does the implementation support ...	Status	Reference	Support	
AddS1	ATM Forum PNNI 1.0 specification ?	M	Intro	 [ ]Yes [ ]No	
AddS2	ATM Forum PNNI 1.0 errata ?	M	Intro	 [ ]Yes [ ]No	
Comments:

Table 2: Additional Specifications Supported

.6	General mobile switch
Prerequisite: Role1
Item	Mobile switch mobility extensions
	Status	Reference	Support	
MS-1	Can the IUT be configured as a mobile switch ?	M	1.1	[ ]Yes [ ]No	
MS-2	Can the IUT be configured to activate and deactivate the mobility extensions ?	M	 2	[ ]Yes [ ]No	
Comments:

Table 3: General mobile switch capabilities

.7	Border node mobile switch

Prerequisite: Role1.1
Item	Border node mobile switch
		Status	Reference	Support	
BN-MS-1	Can physical PNNI interfaces be configured as mobility-enabled in the IUT?		M	1.1	[ ]Yes [ ]No	
BN-MS-2	Can logical PNNI interfaces be configured as mobility-enabled in the IUT?	OPT_4 (from PNNI v1.0 PICS)	O	1.1	[ ]No  [ ]Yes	
BN-MS-3	Does the IUT extract the nodal hierarchy list (NHL) from PNNI Hello messages received on a mobility-enabled interface when the associated PNNI link changes to the PNNI Hello states “2-Way Outside” or “Common Outside” ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-4	Does the IUT add the extracted NHL to the input set of already extracted NHLs ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-5	Does the IUT remove an NHL from the input set of NHLs when the Hello state machine of the associated PNNI link leaves the state “2-Way Outside” or “Common Outside” ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-6	Does the IUT start a new decision process when an NHL is added to or removed from the input set of NHLs		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-7	Does the IUT execute  a decision process that selects zero or one NHL out of the input set of NHLs ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-8	Does the IUT set the outside nodal hierarchy list (ONHL) to the value of the output NHL of the decision process ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-9	Does the IUT create an ONHL information group (IG) with the output ONHL and inserts it into the nodal information group ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-10	Does the IUT delete the ONHL information group (IG) from the nodal information group when the output from the decision process is null ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-11	Does the IUT re-originate the nodal information PTSE if the content of the nodal information group has been modified ?		M	2.2.1.1	[ ]Yes [ ]No	
BN-MS-12	Does the IUT respect the PNNI hold down requirements before re-originating the nodal information PTSE ?		M	PNNI v1.0/5.8.5	[ ]Yes [ ]No	
BN-MS-13	Does the IUT set the sequence number field of the ONHL IG to a value greater than zero when sending the first instance of the ONHL in the nodal information PTSE ?		M	2.2.1	[ ]Yes [ ]No	
BN-MS-14	Does the IUT increase the sequence number field of an ONHL IG when the content of ONHL differs from the one previously advertised ?		M	2.2.1	[ ]Yes [ ]No	
Comments:

Table 4: Border node mobile switch capabilities

.8	Peer group leader / logical group node mobile switch
Prerequisite: Role1.2
Item	Peer group leader node mobile switch
	Prerequisite	Status	Reference	Support	
PGL-MS-1	Does the IUT extract the outside nodal hierarchy list (ONHL) from a received nodal information PTSE ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-2	Does the IUT only consider nodal information PTSEs issued by nodes that are members of the peer group and to which the peer group leader has currently connectivity when extracting the ONHLs ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-3	Does the IUT add the extracted ONHL to the input set of already extracted ONHLs ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-4	Does the IUT remove an ONHL from the input set of ONHLs when a new nodal information PTSE originated from the same node has a different ONHL. ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-5	Does the IUT remove an ONHL from the input set of ONHLs when a new nodal information PTSE originated from the same node does not contain any ONHL ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-6	Does the IUT remove an ONHL from the input set of ONHLs when the peer group leader looses connectivity to the node that originated it ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-7	Does the IUT start  a new decision process when an ONHL is added to or removed from the input set of ONHLs ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-8	Does the IUT execute a decision process that selects zero or one ONHL out of the input set of ONHLs?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-9	Does the IUT set the output ONHL to the value of the output of the decision process  ?		M	2.2.1.2	[ ]Yes [ ]No	
PGL-MS-10	Does the IUT set the peer group leader next higher level binding information to a level and associated peer group id selected from the output ONHL when being the top level peer group leader of the mobile network ?		M	2.2	[ ]Yes [ ]No	
PGL-MS-11	Does the IUT choose  a level from the output ONHL above the highest level among the pre-configured nodes ?		M	2.2	[ ]Yes [ ]No	
PGL-MS-12	Can the maximum level be configured in the IUT?		O	2.2	[ ]Yes [ ]No	
PGL-MS-13	Does the IUT choose  a level from the output ONHL below a configured maximum level ?	PGL-MS-12	M	2.2	[ ]Yes [ ]No	
PGL-MS-14	Which range of values for the maximum level is supported in this IUT (0..104)?	PGL-MS-12	M	2.2	Range:	
PGL-MS-15	Can the minimum level be configured in the IUT?		O	2.2	[ ]Yes [ ]No	
PGL-MS-16	Does the IUT choose a level from the output ONHL above a configured minimum level ?	PGL-MS-15	M	2.2	[ ]Yes [ ]No	
PGL-MS-17	Which range of values for the minimum level is supported in this IUT (0..104)?	PGL-MS-15	M	2.2	Range:	
PGL-MS-18	Does the IUT pass the output ONHL to the next level logical group node if any, when the next level logical group node is a non-mobile node ?		M	2.2.1.2	[ ]Yes [ ]No	
Comments:

Table 5: Peer group leader mobile switch capabilities

Prerequisite: Role1.2
      Item	Logical group node mobile switch
	Status	Reference	Support	
LGN-MS-1	Does the IUT create an ONHL IG when it receives an ONHL from the lower level peer group leader ?	M	2.2.1.3	[ ]Yes [ ]No	
LGN-MS-2	Does the IUT  insert the created ONHL information group into the nodal information group ?	M	2.2.1.3	[ ]Yes [ ]No	
LGN-MS-3	Does the IUT delete the ONHL IG from the nodal information group when the output from the decision process is null ?	M	2.2.1.3	[ ]Yes [ ]No	
LGN-MS-4	Does the IUT re-originate the nodal information PTSE if the content of the nodal information group has been modified ?	M	2.2.1.3	[ ]Yes [ ]No	
LGN-MS-5	Does the IUT respect the PNNI hold down requirements before re-originating the nodal information PTSE ?	M	PNNI v1.0/5.8.5	[ ]Yes [ ]No	
LGN-MS-6	Can a logical group node be configured as mobile in the IUT?	M	2.2	[ ]Yes [ ]No	
LGN-MS-7	Does this IUT set the sequence number field of the ONHL IG to a value greater than zero when sending the first instance of the ONHL in the nodal information PTSE?	M	2.2.1	[ ]Yes [ ]No	
LGN-MS-8	Does the IUT increase the sequence number field of an ONHL IG when the content of ONHL differs from the one previously advertised ?	M	2.2.1	[ ]Yes [ ]No	
Comments:

Table 6: Logical group node mobile switch capabilities

.9	Border node access point switch
Prerequisite: Role2
       Item	Border node access point switch
	Prerequisite	Status	Reference	Support	
BN-AP-1	Can the IUT be configured as an access point ?		M		[ ]Yes [ ]No	
BN-AP-2	Can the IUT be configured to activate and deactivate the mobility extensions ?		M		[ ]Yes [ ]No	
BN-AP-3	Can physical PNNI interfaces be configured as mobility-enabled in the IUT?		M	1.1	[ ]Yes [ ]No	
BN-AP-4	Can logical PNNI interfaces be configured as mobility-enabled in the IUT?	OPT_4 (from PNNI v1.0 PICS)	O	1.1	[ ]No  [ ]Yes	
BN-AP-5	Can the value of the highest level that can be advertised in a partial nodal hierarchy list be configured in the IUT?		O	2.2.2	[ ]Yes [ ]No	
BN-AP-6	Which range of values for the highest advertised level (0..104) can be configured in the IUT?	BN-AP-5	M	2.2.2	Range:	
BN-AP-7	Does the IUT set a partial nodal hierarchy list consisting exclusively of the full nodal hierarchy list up to the highest advertised level ?	BN-AP-5	M	2.2.2	[ ]Yes [ ]No	
BN-AP-8	Does the IUT support the configuration of a different highest advertised level for each mobility-enabled interface ?	BN-AP-5	O	2.2.2	[ ]Yes [ ]No	
BN-AP-9	Does the IUT send in the Hello message a partial nodal hierarchy list that has the exact same format as a nodal hierarchy list ?	BN-AP-5	M	2.2.2	 [ ]No  [ ]Yes	
Comments:

Table 7: Border node access point switch capabilities