Technical Committee PNNI addendum for mobility extensions version 1.0 AF-RA-0123.000 May, 1999 (c) 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. for exceptional information, or S. for supplemental information, respectively, for cross reference purposes, where 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 AF-RA-0123.000 PNNI addendum for mobility extensions v1.0 May, 1999 PNNI addendum for mobility extensions v1.0 AF-RA-0123.000 May, 1999 Page 6 of 36 ATM Forum Technical Committee ATM Forum Technical Committee Page 5 of 36