Technical Committee PHY/MAC Identifier Addendum to UNI Signaling 4.0 AF-CS-0135.000 November, 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 1. Introduction This addendum to the ATM Forum UNI Signalling 4.0 (SIG 4.0) [1] Specification is intended for use with UNIs that use certain ATM PHY layers which are typically associated with Residential Broadband access networks. 1.1 Architectural Model Certain ATM Physical layers have properties which are atypical of, e.g., SONET/SDH based PHYs. These properties affect the service provided by the PHY layer to the ATM layer. These PHYs are modeled as supporting multiple physical layer connections, which in turn support a single instance of the ATM layer. This may occur, for example, in ATM-based shared media access networks, or when the PHY layer provides more than one physical layer connection, each of which has different values of PHY layer (as opposed to ATM layer) Quality-of-Service parameters. One example of the former is the IEEE 802.14 Media Access Control (MAC) protocol [2]. An example of the latter is dual latency ADSL [3], where latency paths are modeled as PHY connections. Figure 1.1 is an abstract model of the relationship between such a PHY and the ATM layer. The modeling techniques of the OSI Reference Model are used as a descriptive tool. The model represents either an ATM end-system or an NT21, and an ATM access node2 at opposite sides of a UNI. The case shown uses a point-to-point physical media. For each system, there is one Physical Layer entity bound to the physical media and to a PHY-service-access point. There are one or more point-to-point PHY layer connections between the PHY layer entities in the ATM access node and the end system or NT2. Each such point-to-point PHY connection terminates at each end in a PHY-connection-endpoint. The PHY-connection is identified (explicitly or implicitly) within the PHY layer by a PHY-protocol-connection-identifier. In a typical PHY, the PHY-protocol-connection-identifier is an implicit selection of part of the framing structure. The PHY-connection-endpoint is identified by a PHY-connection-endpoint-identifier (which in the remainder of this specification is called the PHY/MAC Layer Identifier). Figure 1.1 Architectural model of PHY identifiers 1 NT2 (Network Termination, Type-2): A network element that terminates the access network on the customer premises side of the 'U' interface and supports one or more 'T' interfaces for attachment of Terminal Equipment (TE). The NT2 may implement control and signaling functions. 2 AN (Access Node): A network element that terminates one or more subscriber lines on the network side of the 'U' interface and supports one or more 'V' interfaces for attachment to the broadband network. The AN may implement control and signaling functions. There is exactly one instance of an ATM layer entity bound to each PHY-service-access-point; i.e., there is only one copy of the VPI/VCI space, one set of reserved VPI/VCI and so on. When a virtual connection is established, the ATM layer entity must bind that VC to a PHY-connection-endpoint which is identified by a PHY/MAC-layer identifier. This binding must be coordinated at each side of the UNI, such that cells are not transmitted by the access node on a different PHY-connection than the end-system expects (or vice-versa), and also such that traffic contracts, QoS objectives and policy objectives can be satisfied. For SVCs, the coordination is done using the extensions to the SIG 4.0 [1] specification defined in this specification. For PVCs, the ILMI MIB is [to be] extended as defined in [4]. For the shared media case (which is not shown), there are multiple ATM end-systems or NT2s on the same physical media. A Media Access Control (MAC) sublayer is present in the PHY layer. PHY-connections may be point-to-point or unidirectional point-to-multipoint (in the direction from the Access Node to the end-system or NT2). Point-to-multipoint PHY connections are used to efficiently support point-to-multipoint ATM VCs. In the end-system or NT2, there is one PHY-service-access-point. In the Access Node, there would be one PHY-service-access-point for each ATM end-system or NT2, and at least one for point-to-multipoint PHY connections. The PHY/MAC identifier uniquely identifies the ATM end-system or NT2, as well as the endpoint of each PHY-connection for point-to-point PHY-connections. 1.2 Interfaces The encodings and procedures of this specification have local significance only. Since at present, all ATM PHYs which have multiple PHY layer connections which need to be bound to ATM VCs are at the UNI, the encodings and procedures of this specification are defined only at the UNI, and not at the PNNI, BICI or AINI. Should a future PHY which has multiple PHY layer connections appear to be applicable at these interfaces, or should there by interest in the future in offering a PNNI, BICI or AINI across one of the existing PHYs which have this property, then corresponding procedures will need to be developed for these interfaces. 1.3 Backward Compatibility and Control of Negotiation The procedures and encodings of this addendum to the SIG 4.0 [1] specification are designed to be backward compatible with implementations that do not support them. However, for some networks, support of these procedures and encodings is essential. For MACs and PHYs which require PHY/MAC identifier assignment by the network, it is presumed to be essential to correct operation of the MAC or PHY that the network assign, and the user accept assignment of, the PHY/MAC identifier and use it in conjunction with the virtual connection. In this case, the encodings and procedures of this addendum are mandatory. However, it is also presumed that since such UNIs would require equipment at each side be designed to support the corresponding PHY and MAC layers, the additional signalling capabilities defined in this specification would also be supported. For MACs and PHYs which allow negotiation of the PHY/MAC identifier between the user and the network, it is presumed that if either the user or the network does not negotiate, the VC can be bound to a default value of the PHY/MAC identifier. The procedures of section 5 of this addendum are designed to allow for the cases that either the user side, the network side or both sides of the UNI do not support the procedures of this addendum, and the VC to PHY/MAC identifier binding falls back to the default. The negotiation procedures are also designed to give the network side of the UNI the opportunity to determine the outcome of the negotiation, in a fashion similar to VPCI/VCI negotiation in SIG 4.0 [1]. Codings of the PHY/MAC identifier include indications that the coding is "Required", "Preferred" or that the sender has "No preference". At origination, the user side of the interface can only signal a "Preferred" or "No preference" value in the SETUP message, and must accept the "Required" value from the network in the first response to the SETUP message. At the destination, the network side can signal a "Required" value in the SETUP message, if it wishes to preclude negotiation, or it may indicate a "Preferred" or "No preference" value if it wishes to allow the user side to determine the value of the PHY/MAC identifier. 1.4. References [1] ATM Forum (1996) ATM User-Network Interface (UNI) Signalling Specification Version 4.0, af-sig-0061.00 [2] IEEE 802.14 Cable-TV access method and physical layer specification [3] ITU-T G.996.1 Asymmetric Digital Subscriber Line (ADSL) Transceivers [4] ATM Forum ILMI Addendum for ADSL Dual Latency, (TBD) [5] 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)). [6] 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)). [7] ITU (1995) Q.2931 B-ISDN DSS2 User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control. 1.5. Acronyms ADSL Asynchronous Digital Subscriber Line NT2 Network Termination Type 2 OSI Open Standards Interconnection MAC Media Access Control PMD Physical Media Dependent Sublayer PHY Physical layer SDH Synchronous Digital Hierarchy TC Transmission Convergence Sublayer 2. Modification of Point-to-Point Messages The message coding in SIG 4.0 apply with the additions specified in this section. Table 2-1 lists the existing SIG 4.0 [1] messages that have had their content modified to support PHY/MAC-layer identifier. Table 2-1 Modified SIG 4.0 messages Message Reference ALERTING 2.1 CALL PROCEEDING 2.2 CONNECT 2.3 SETUP 2.4 2.1. ALERTING Table 2-2 contains additions to the structure of the ALERTING message shown in Table 3-2/Q.2931 Table 2-2 ALERTING message additional content Message type: ALERTING Significance: global Direction: both Information element Reference Direction Type Length PHY/MAC-layer identifier 3.1 Both O (Note 1) 9-10 Note 1: If this is the first message in response to a SETUP message, mandatory in the N->U direction in networks where the PHY/MAC-layer identifier is assigned by the Network, and optional in both directions in networks where the PHY/MAC-layer identifier is negotiated between the Network and the User. Otherwise not present. 2.2. CALL PROCEEDING Table 2-3 contains additions to the structure of the CALL PROCEEDING message shown in Table 3-2/Q.2931 Table 2-3 CALL PROCEEDING message additional content Message type: CALL PROCEEDING Significance: global Direction: both Information element Reference Direction Type Length PHY/MAC-layer identifier 3.1 both O (Note 1) 9-10 Note 1: Mandatory in the N->U direction in networks where the PHY/MAC-layer identifier is assigned by the Network, and optional in both directions in networks where the PHY/MAC-layer identifier is negotiated between the Network and the User. Otherwise not present. 2.3. CONNECT Table 2-4 contains additions to the structure of the CONNECT message shown in Table 3-2/Q.2931 Table 2-4 CONNECT message additional content Message type: CONNECT Significance: global Direction: both Information element Reference Direction Type Length PHY/MAC-layer identifier 3.1 both O (Note 1) 9-10 Note 1: If this is the first message in response to a SETUP message, mandatory in the N->U direction in networks where the PHY/MAC-layer identifier is assigned by the Network, and optional in both directions in networks where the PHY/MAC-layer identifier is negotiated between the Network and the User. Otherwise not present. 2.4. SETUP Table 2-5 contains additions to the structure of the SETUP message shown in Table 3-2/Q.2931. Table 2-5 SETUP message additional content Message type: SETUP Significance: global Direction: both Information element Reference Direction Type Length PHY/MAC-layer identifier 3.1 both O (Note 1) 9-10 Note 1: Mandatory in the N->U direction, in networks where the PHY/MAC-layer identifier is assigned by the Network. Optional in both directions in networks where the PHY/MAC-layer identifier is negotiated between the Network and the User. Otherwise, not present. 3. Information Elements The information elements and coding rules of SIG 4.0 [1] shall apply with the addition listed below. Table 3-1 contains the information element coding needed for the new PHY/MAC-layer identifier information element. 8 7 6 5 4 3 2 1 1 1 1 0 1 1 0 1 PHY/MAC-layer identifier Table 3-1 Coding of additional information element identifier 3.1. PHY/MAC-Layer identifier The PHY/MAC-layer identifier information element provides additional information for the purposes of assigning an ATM Virtual Connection to a PHY or MAC-layer entity. This information concerns only the PHY or MAC layer at the UNI, and is local in nature (i.e., is not progressed beyond the local UNI). This information element is optionally present in the SETUP message and optionally present in the first response to the SETUP message. The PHY/MAC-layer identifier information element is coded as shown in figure 3-1. The maximum length of this information element is 10 octets. Bits 8 7 6 5 4 3 2 1 Octets PHY/MAC-layer identifier information element 1 1 1 0 1 1 0 1 1 Information element identifier 1 Coding Information Element Instruction Field 2 Ext Standard Flag Reserved IE Action Indicator Length of PHY/MAC-layer identifier 3 Length of PHY/MAC-layer identifier (continued) 4 Related PHY/MAC Layer Standard 5 Identifier Type 6 Identifier Length 6.1 6.2 Identifier Value to 6.m Note 1: The Information Element Instruction Field shall be coded with the Flag set to 1 " follow explicit instructions" and with the IE action indicator coded 00 "Clear Call". Figure 3-1 PHY/MAC-layer identifier Information Element Coding Standard (Octet 2) Bits 7 6 1 1 ATM Forum specific Type of PHY/MAC-layer identifier (octet 5) This field indicates the type of PHY/MAC identifier contained in octet 6 and following octets. It is coded as follows: 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 IEEE 802.14 (Note 2) 0 0 0 0 0 0 1 0 ADSL (Note 3) All other values reserved Note 1: Each PHY/MAC-layer standard requiring a different set or structure of identifiers (coded in octet group 6) shall use a different value of octet 5. Note 2: See Annex A for details when this information element is used for IEEE 802.14 networks. Note 3: See Annex B for details when this information element is used for ADSL networks. Identifier type, length and content (octet group 6) Octet group 6 is used to define an identifier or part of an identifier composed of multiple parts. Identifier type (Octet 6) (Note 1) 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 MAC layer protocol connection identifier (note 2) 0 0 0 0 0 0 1 0 PHY layer protocol connection identifier (note 3) All other values are reserved Note 1: The value coded in the identifier type field is independent of the related PHY/MAC-layer standard field (octet 5). Note 2: When the identifier type is coded as MAC-layer protocol connection identifier, the content of the Identifier value field is an identifier which is significant only to the MAC layer protocol for differentiating between MAC layer connections or associations. Note 3: When the identifier type is coded as PHY-layer protocol connection identifier, the content of the Identifier value field is an identifier which is significant only to the PHY layer protocol for differentiating between PHY layer connections or associations. Identifier length The identifier length shall be a binary number indicating the length (in octets) of the identifier value. Identifier value The identifier value shall be according to the standard identified in octet 5 Coding of the IEEE 802.14 MAC layer protocol connection identifier When octet 5 is coded as IEEE 802.14, then octet group 6 follows. Octet 6 shall be coded as MAC layer protocol connection identifier. The length contained in octet 6.1 shall be three octets. Octets 6.2, 6.3 and 6.4 shall contain the 24 bit 802.14 logical queue identifier. Coding of the ADSL PHY layer protocol connection identifier When octet 5 is coded as ADSL, then octet group 6 follows. The length contained in octets 6.1 shall be two octets. Octets 6.2 shall contain the path selection for the ADSL downstream (from network to user), and octet 6.3 shall contain the path selection for the ADSL upstream (from user to network). Octets 6.2 and 6.3 shall each be coded as follows: Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 Fast Path Required 0 0 0 0 0 0 1 0 Interleaved Path Required 1 0 0 0 0 0 0 1 Fast path preferred 1 0 0 0 0 0 1 0 Interleaved path preferred 1 1 1 1 1 1 1 1 No preference All other values are reserved. 4. Procedures for networks where MAC/PHY layer identifiers are assigned by the network The procedures of this section are in addition to the procedures of SIG 4.0 [1] and apply only to networks which require use of PHY/MAC-layer identifiers which are assigned by the network. The PHY/MAC-layer identifier is associated with an ATM virtual connection by the Network, and is not subject to negotiation with the User. See, for example, Annex A. 4.1 PHY/MAC-layer identifier - origination The following procedures are added to clause 5.1/Q.2931: The PHY/MAC-layer identifier information element shall not be present in the SETUP message. If it is present, it shall be treated as an unexpected recognized information element (see 5.6.8/Q.2931). The network shall indicate the selected PHY/MAC-layer identifier in the PHY/MAC-layer identifier information element in the first message returned in response to the SETUP message. If the PHY/MAC-layer identifier information element is not present, then the user shall clear the call with Cause #96 "Mandatory information element missing". 4.2. PHY/MAC-layer identifier - destination The following procedure is added to clause 5.2/Q.2931: The PHY/MAC-layer identifier information element shall be present in the SETUP message. If it is absent, then the user shall clear the call with Cause #96 "Mandatory information element missing". The PHY/MAC-layer identifier information element shall not be present in the first message returned in response to the SETUP message. If it is present, it shall be treated as an unexpected recognized information element (see 5.6.8/Q.2931). 4.3 ILMI and Signaling Channel For networks where the MAC/PHY identifier is assigned by the network, the MAC/PHY identifier to be used for the signaling and ILMI Virtual Channels shall be assigned in a manner defined by the relevant MAC or PHY layer specification. 4.4 Proxy Signaling For a Proxy Signaling Agent (PSA), the above procedures for the PHY/MAC-layer identifier apply only when the UNI the VC is being established on is a UNI of a type where these procedures would apply. 4.5 Virtual UNI The virtual UNI capability is not applicable. 5. Procedures for networks where MAC/PHY layer identifiers may be negotiated between the user and the network The procedures of this section are in addition to the procedures of SIG 4.0 [1] and apply only to networks which require use of PHY/MAC-layer identifiers which may be negotiated between the user and the network. See, for example, Annex B. The following procedures are added to clause 5.1/Q.2931: 5.1. PHY/MAC-layer identifier - origination If the user does not support negotiation of the PHY/MAC-layer identifier, then it shall omit the PHY/MAC-layer identifier information element from the SETUP message. If the user supports negotiation of the PHY/MAC-layer identifier, then it shall always include the PHY/MAC-layer identifier information element in the SETUP message, with Octets 6.2 and 6.3coded to indicate either a preferred value or "No Preference". If the PHY/MAC-layer identifier information element is present in the SETUP message, and octets 6.2 and 6.3 are coded with any value other than either a preferred value or "No Preference", then the network shall clear the call with Cause #100, "Invalid information element contents". If the PHY/MAC-layer identifier information element was present in the SETUP message, and the network supports negotiation of the PHY/MAC-layer identifier, then the network shall include the PHY/MAC-layer identifier information element in the first message returned in response to the SETUP message. The value of octets 6.2 and 6.3 shall be set to a "Required" value. If possible, this value should correspond to the preferred PHY/MAC-layer identifier indicated in the SETUP message. If the PHY/MAC-layer identifier information element was not present in the SETUP message, or the network does not support negotiation of the PHY/MAC-layer identifier, then the network shall not include the PHY/MAC-layer identifier information element in the first message returned in response to the SETUP message. In this case, the default value of the PHY/MAC-layer identifier shall be used. If the PHY/MAC-layer identifier information element is present in the first response to the SETUP message, then the indicated value(s) of the PHY/MAC-layer identifier shall be used by the user and the network. If it is absent, then the default value of the PHY/MAC-layer identifier shall be used by both the user and the network. However, if the PHY/MAC-layer identifier information element is present in the first response to the SETUP message, but was not present in the SETUP message, the user shall treat it as an unrecognized information element (see 5.6.8 /Q.2931). If the PHY/MAC-layer identifier information element is present in the first response to the SETUP message, and octet 6.2 or octet 6.3is coded with any value other than a 'required' value, then the user shall clear the call with Cause #100, "Invalid information element contents". 5.2. PHY/MAC-layer identifier - destination If the network does not support negotiation of the PHY/MAC-layer identifier, then it shall omit the PHY/MAC-layer identifier information element from the SETUP message. In this case, the default value(s) of the PHY/MAC-layer identifier shall apply for the virtual connection. If the network supports negotiation of the PHY/MAC-layer identifier, then it shall always include the PHY/MAC-layer identifier information element in the SETUP message, with Octet 6.2 and octet 6.3 coded to indicate either: a) "No Preference", if any value(s) of the PHY/MAC-layer identifier is (are) acceptable b) a required value, if it wishes to assign PHY/MAC-layer identifier(s) for the virtual connection without the possibility for the user to select a different value c) a preferred value, if it has value(s) of the PHY/MAC-layer identifier(s) it wishes to use, but will permit the user to select a different value. If the user does not support negotiation of the PHY/MAC-layer identifier, it shall not include the PHY/MAC-layer identifier information element in the first response to the SETUP message. In that case, the default value(s) of the PHY/MAC-layer identifier shall apply for the virtual connection. If the user supports negotiation of the PHY/MAC-layer identifier, it shall include the PHY/MAC-layer identifier information element in the first response to the SETUP message, with Octet 6.2 and Octet 6.3 coded as: a) a required value if the PHY/MAC-layer identifier information element in the SETUP message was coded to indicate "No preference" or a preferred value. In the latter case, this value should correspond, if possible, to the preferred PHY/MAC-layer identifier indicated in the SETUP message. b) the same value contained in the SETUP message, if the PHY/MAC-layer identifier in the SETUP message was coded to indicate a required value. If the PHY/MAC-layer identifier information element was not present in the SETUP message, it shall not be present in the first message returned in response to the SETUP message. If it is present, the network shall treat it as an unrecognized information element (see 5.6.8/Q.2931). If the PHY/MAC-layer identifier information element is present in the first response to a SETUP message, and octet 6.2 or 6.3is coded with any value other than a required value, then the network shall clear the call with Cause #100, "Invalid information element contents". If a required value was present in the PHY/MAC-layer identifier in the SETUP message, but a different value is present in the corresponding octet in the first response to the SETUP message, then the network shall clear the call with Cause #100, "Invalid information element contents" 5.3 ILMI and Signaling Channel For networks where the MAC/PHY identifier is negotiated between the user and the network, the MAC/PHY identifier to be used for the signaling and ILMI Virtual Channels shall be the default value defined by the relevant MAC or PHY layer specification. 5.4 Proxy Signaling For a Proxy Signaling Agent (PSA), the above procedures for the PHY/MAC-layer identifier apply only when the UNI the VC is being established on, is a UNI of a type where these procedures would apply. 5.5 Virtual UNI The virtual UNI capability is not applicable. 6. Protocol Implementation Conformance Statement (PICS) 6.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). 6.1.1 Scope Section 6.3 provides the PICS proforma for PHY/MAC identifiers, as specified in this document in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2 [6]. In most cases, statements contained in notes in the specification, which were intended as information, are not included in the PICS. 6.1.2 Definitions This following terms defined in ISO/IEC 9646-1[5] are used below: * 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. 6.1.3 Acronyms IUT Implementation under test M Mandatory requirements (these are to be observed in all cases) 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". PICS Protocol Implementation Conformance Statement 6.1.4 Conformance The supplier of a protocol implementation which is claimed to conform to the SIG 4.0 [1] with the PHY/MAC-layer Identifier extension 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. 6.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: * The PHY/MAC identifier extension (to the SIG 4.0 [1]) as defined in this document 6.3 PICS Proforma 6.3.1 Global statement of conformance The implementation described in this PICS meets all of the mandatory requirements of the reference protocol. [ ] YES [ ] NO 6.3.2 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. 6.3.3 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. 6.3.4 Roles Item Number Item Description Status Reference Support R1 Implementation is User side of UNI? O.1 (note 1) Yes__No__ R2 Implementation is Network side of UNI? O.1 Yes__No__ R3 Implementation PHY/MAC allows negotiation of PHY/MAC identifiers? O.2 (note 2) Yes__No__ R4 Implementation PHY/MAC requires assignment of a PHY/MAC identifier by the network? O.2 Yes__No__ R5 Implementation is IEEE 802.14 Cable TV access method & physical layer specification? O.3 (note 3) Yes__No__ R6 Implementation is dual latency ADSL? O.3 Yes__No__ Note 1: Exactly one of these options must be supported Note 2: Exactly one of these options must be supported. Others may be subject of future versions of this specification. Note 3: Exactly one of these options must be supported. Others may be subject of future versions of this specification. 6.3.5 Encoding Item Number Item Description Status Predicate (note 3) Reference Support E1 If the implementation is Network side,, does it include the PHY/MAC-layer identifier information element in a SETUP message? M R2, R4 2.4 Yes__No__ E2 If the implementation is Network side, is it capable of including the PHY/MAC-layer identifier information element in the first response to a SETUP message (i.e., a CONNECT, ALERTING or CALL PROCEEDING message)? M R2, R4 2.1, 2.2, 2.3 Yes__No__ E3 If the implementation is User sideand uses an IEEE 802.14 UNI, does it omit the PHY/MAC-layer identifier information element from any message that it sends? M R1, R4 2.1-2.4, 4.1, 4.2 Yes__No__ E4 Is the implementation capable of including the PHY/MAC-layer identifier information element in a - SETUP message? - CONNECT message? -ALERTING message? -CALL PROCEEDING message? O R3 2.1-2.4 Yes__No__ Yes__No__ Yes__No__ Yes__No__ E5 Is the PHY/MAC-layer identifier information element coded as shown in Figure 3-1? M 3.1 Yes__No__ E6 Is Octet 5 encoded to correspond to the type of MAC and/or PHY which is present at the UNI? - Octet 6 coded as "MAC layer protocol connection identifier" if there is a MAC layer present, or "PHY layer protocol identifer otherwise? - Length contained in Octet 6.1 equal to the length of the MAC or PHY layer protocol connection identifier associated with the MAC or PHY? - Remaining octets (6.2 etc.) equal to the value of the MAC or PHY layer protocol connection identifier? M R4 or R3 3.1 Yes__No__ Yes__No__ Yes__No__ Yes__No__ Note 3: Unless otherwise noted, if multiple predicates are present, they shall all be TRUE for the question to apply. 6.3.6 Procedures - User Side Item Number Item Description Status Predicate Reference Support UP1 , Does the implementation accept assignment of the PHY/MAC identifier by the network? M R1, R4 4.0 Yes__No__ UP2 Does the implementation negotiate the PHY/MAC identifier with the network? O.3 (note 4) R1, R3 5.0 Yes__No__ UP3 Does the implementation NOT negotiate the PHY/MAC identifier with the network? O.3 R1,R3 5.0 Yes__No__ UP4 If the PHY/MAC-layer identifier information element is not present in an incoming SETUP message or the first response to an outgoing SETUP message, does the implementation clear the call with Cause #96, "Mandatory information element missing" ? M UP1 4.1, 4.2 Yes__No__ UP5 If the implementation does not support negotiation, does it omit the PHY/MAC identifier from the SETUP message and use the default value? M UP3 5.1 Yes__No__ UP6 If the implementation supports negotiation, does it include the PHY/MAC-layer identifier information element in an outgoing SETUP message? M UP3 5.1 Yes__No__ UP7 If the PHY/MAC-layer identifier information element is included in an outgoing SETUP message, are octets 6.2 and 6.3 coded to indicate a preferred value? M UP6 5.1 Yes__No__ UP8 If the PHY/MAC-layer identifier information element is included in the first response to an outgoing SETUP message, and the outgoing SETUP message contained a PHY/MAC-layer identifier information element, does the implementation use the value indicated in the PHY/MAC-layer identifier information element? M UP2, E4 5.1 Yes__No__ UP9 If the PHY/MAC-layer identifier information element is included in the first response to an outgoing SETUP message, but the outgoing SETUP message did not contain a PHY/MAC-layer identifier information element, does the implementation treat it as an unrecognized information element? M UP2 5.1, 5.6.8/Q.2931 Yes__No__ UP10 If the PHY/MAC-layer identifier information element is not included in the first response to an outgoing SETUP message, and the outgoing SETUP message contained a PHY/MAC-layer identifier information element, does the implementation use the default value of the PHY/MAC-layer identifier? M UP2 5.1 Yes__No__ UP11 If the PHY/MAC-layer identifier information element is included in the first response to an outgoing SETUP message, but the value contained in octet 6.2 or 6.3 is not a "Required" value, does the implementation clear the call with Cause #100, "Invalid information element content"? M UP2 5.1 Yes__No__ UP12 Does the implementation encode octets 6.2 and 6.3 of the PHY/MAC-layer identifier information element to : - a "No Preference" value or a "Preferred" value? M UP2 5.1 Yes__No__Yes__No__ UP13 If the implementation does not support negotiation, does it omit the PHY/MAC-layer identifier information element from the first response to an incoming SETUP message and use the default value? M UP3 5.2 Yes__No__ UP14 If the implementation supports negotiation, and the PHY/MAC-layer identifier information element is present in an incoming SETUP message, does it include the PHY/MAC identifier information element in the first response to the incoming SETUP message? M UP2 5.2 Yes__No__ UP15 If the value of the PHY/MAC-layer identifier indicated in the incoming SETUP message is coded to indicate a "Preferred" value or "No preference", does the implementation indicate a "Required" value in the PHY/MAC-layer identifier? M UP2 5.2 Yes__No__ UP16 If the value of the PHY/MAC-layer identifier indicated in the incoming SETUP message is coded to indicate a "Required" value, does the implementation indicate the same value in the PHY/MAC-layer identifier information element in the first response to the incoming SETUP message? M UP2 5.2 Yes__No__ UP17 If the implementation supports negotiation, and the PHY/MAC-layer identifier information element is absent from an incoming SETUP message, does it omit the PHY/MAC-layer identifier information element from the first response to the incoming SETUP message? M UP2 5.2 Yes__No__ Note 4: Exactly one of these options shall be supported. If negotiation is not supported, then the user side procedures are the same as those in SIG 4.0 [1]. 6.3.7 Procedures - Network Side Item Number Item Description Status Predicate Reference Support NP1 Does the implementation assign PHY/MAC identifiers to the User? M R1, R4 4.1 Yes__No__ NP2 Does the implementation negotiate the PHY/MAC identifier with the User?? O.4 (note 5) R1, R3 5.0 Yes__No__ NP3 Does the implementation NOT negotiate the PHY/MAC identifier with the network? O.4 R1, R3 5.0 Yes__No__ NP4 If a PHY/MAC-layer identifier information element is present in an incoming SETUP message, does the implementation treat it as an unexpected recognized information element? M NP1 4.1, 5.6.8/Q.2931 Yes__No__ NP5 Does the implementation include a PHY/MAC-layer identifier information element in the first response to an incoming SETUP message? M NP1 4.1 Yes__No__ NP6 Does the implementation include a PHY/MAC-layer identifier information element in an outgoing SETUP message? M NP1 4.2 Yes__No__ NP7 If a PHY/MAC-layer identifier information element is present in the first response to an outgoing SETUP message, does the implementation treat it as an unexpected recognized information element? M NP1 4.2 Yes__No__ NP8 Does the implementation set the value contained in octets 6.2 and bits 8-3 of octet 6.3 of the PHY/MAC-layer identifier information element in the first response to a SETUP message to the 802.14 station's primary local identifier? M NP1 A.2.2 Yes__No__ NP9 For point-to-point connections, does the implementation set the value contained in octets 6.2 and bits 8-3 of octet 6.3 of the PHY/MAC-layer identifier information element in the SETUP message to the 802.14 station's primary local identifier? M NP1 A.2.2 Yes__No__ NP10 If a PHY/MAC-layer identifier information element is present in an incoming SETUP message and octets 6.2 and 6.3 are coded with any value other than a "preferred" value or "no preference", does the implementation clear the call with Cause #100 "Invalid information element content"? M NP2 5.1 Yes__No__ NP11 If a PHY/MAC-layer identifier information element is present in an incoming SETUP message and octets 6.2 and 6.3 are coded with a "preferred" value or "no preference", does the implementation include the PHY/MAC-layer identifier information element in the first response to the SETUP message? Are octets 6.2 and 6.3 set to a "required value"? M NP2 5.1 Yes__No__ Yes__No__ NP12 If a PHY/MAC-layer identifier information element is absent from an incoming SETUP message, does the implementation omit the PHY/MAC-layer identifier information element from the first response to the SETUP message and use the default value for the PHY/MAC-layer identifier? M NP2 5.1 Yes__No__ NP13 If the implementation does not support negotiation, does it omit the PHY/MAC-layer identifier information element from the first response to the SETUP message and use the default value for the PHY/MAC-layer identifier?? M NP3 5.1 Yes__No__ NP14 If the implementation does not support negotiation, does it omit the PHY/MAC-layer identifier information element from the outgoing SETUP message and use the default value? M NP3 5.2 Yes__No__ NP15 If the implementation does support negotiation, does it include the PHY/MAC-layer identifier information element in an outgoing SETUP message M NP2 5.2 Yes__No__ NP16 Does the implementation encode octets 6.2 and 6.3 of the PHY/MAC-layer identifier information element in an outgoing SETUP message to: - "No preference", a "Required" value, or a "Preferred" value? M NP2 5.2 Yes__No__ NP17 If the PHY/MAC-layer identifier information element is included in the first response to an outgoing SETUP message, but was omitted from the SETUP message, does the implementation treat it as an unexpected recognized information element or an unrecognized information element? M NP3 5.2, 5.6.8/Q.2931 Yes__No__ NP18 If the PHY/MAC-layer identifier information element is included in the first response to an outgoing SETUP message, but the values contained in octets 6.2 and 6.3 are not a "Required" value, does the implementation clear the call with Cause #100, "Invalid information element content"? M NP2 5.2 Yes__No__ NP19 If the value contained in octet 6.2 or 6.3 of PHY/MAC-layer identifier information element included in the outgoing SETUP message was a "required" value, but the respective value contained in octet 6.2 or 6.3 of PHY/MAC-layer identifier information element included in the first response to SETUP message is different than that contained in the SETUP message, does the implementation clear the call with Cause #100, "Invalid information element content"? M NP2 5.2 Yes__No__ Note 5: Exactly one of these options shall be supported. If negotiation is not supported, then the network side procedures are the same as those in SIG 4.0 [1]. 6.3.8 Supplemental PICS for implementations over IEEE 802.14 Cable TV access method and physical layer specification Item Number Item Description Status Predicate Reference Support CA1 If the implementation is at the user side of the UNI, does the implementation accept assignment of the PHY/MAC-layer identifier by the network? M R1,R5 4.1 Yes__No__ CA2 If the implementation is at the network side of the UNI, does the implementation assign the PHY/MAC-layer identifier? M R2,R5 4.1 Yes__No__ CA3 Is Octet 5 encoded as "IEEE 802.14"? - Octet 6 encoded as "MAC layer protocol identifier? - the length contained in Octet 6.1 equal to 3? - the content of Octets 6.2 through 6.4 equal to an IEEE 802.14 logical queue identifier? M R2,R5 3.1 Yes__No__ Yes__No__ Yes__No__ Yes__No__ CA4 If the implementation is at the user side of the UNI, does the implementation clear the call with Cause #100, "Invalid information element content" if value contained in octets 6.2 and bits 8-3 of octet 6.3 of the PHY/MAC-layer identifier information element: has not been assigned to the station? for a point-to-point VCC, is not the same as the station's primary local identifier, ? M R1,R5 A.2.2 Yes__No__ Yes__No__ CA5 If the implementation is at the network side of the UNI, does it set the value contained in octets 6.2 and bits 8-3 of octet 6.3 of the PHY/MAC-layer identifier information element to: a local identifier which has been assigned to the station? the station's primary local identifier, if the connection being established is a point-to-point VCC? M NP1,R5 A.2.2 Yes__No__ Yes__No__ 6.3.9 Supplemental PICS for implementations over dual latency ADSL Item Number Item Description Status Predicate Reference Support DL1 Does the implementation negotiate the PHY/MAC-layer identifier? O.1 R6 5.0 Yes__No__ DL2 Does the implementation NOT negotiate the PHY/MAC-layer identifier? O.1 (Note 6) R6 5.0 Yes__No__ DL3 Is Octet 5 encoded as "ADSL"? - Octet 6 encoded as "PHY layer protocol identifier? - the length contained in Octet 6.1 equal to 2? - the content of Octets 6.2 and 6.3 encoded as "Fast path required", "Interleaved path required", "Fast path preferred", "Interleaved path preferred" or "No Preference"? M DL1,R6 3.1 Yes__No__ Yes__No__ Yes__No__ Yes__No__ DL4 Are the latency paths bound to either the values negotiated (if negotiation is used) or the default (if negotiation is not used) M R1,R6 B.2.2 Yes__No__ DL5 Are latency paths negotiated in both directions? M DL1,R6 B.2.2 Yes__No__ DL6 Is the default latency path the interleaved path M R6 B.2.2 Yes__No__ Note 6: Exactly one of these options shall be supported. Annex A (Normative) Use of the PHY/MAC-layer identifier in ATM over CATV-based Broadband Metropolitan Area Networks One MAC Layer that supports multiple MAC layer identifiers is the IEEE 802.14 Protocol Standard for CATV Based Broadband Metropolitan Area Networks (see [2]). IEEE 802.14 is designed to fully support the ATM layer, including ATM SVCs and PVCs. Note: The IEEE 802.14 media access control (MAC) layer is treated as part of the PHY layer by the ATM layer A.1. Background The IEEE 802.14 MAC layer has a 14-bit Local ID, which is composed of ATM layer VPI field and two most significant bits. The VPI bits are overloaded (i.e., have two sets of semantics). From the perspective of the ATM layer, the VPI field identifies a point-to-point VP link from the 802.14 draft Head-end Controller (HC) to a station, or a point-to-multipoint VP link from the HC to all stations. The most significant two bits of the Local ID are contained entirely within the MAC layer, and do not affect the definition of the ATM Layer. The MAC layer station registration procedures assign a primary local ID to the station. Additional local IDs are used for VPCs, for certain system control functions, and for point-to-multipoint VCCs that have one or more station as a leaf. In addition, the 802.14 ( draft) standard has a notion of a logical queue. The fully qualified logical queue ID consists of the 14-bit local identifier and a 10-bit local queue ID. Each virtual connection is assigned by the network to a logical queue at the time it is established according to the below. The algorithm for this assignment is network specific. A.2. Use of the PHY/MAC Layer -Identifier procedures A.2.1 Coding of the PHY/MAC-layer identifier The Identifier Value field of octets 6.2, 6.3 and 6.4 of the PHY/MAC-Connection-identifier information element is coded to contain the 24-bit IEEE 802.14 logical queue identifier. See IEEE 802.14 for further details. A.2.2 Procedures The procedures of section 4 apply to CATV-based broadband metropolitan area networks. In addition, the following applies to the content of the PHY/MAC-layer identifier information element: a) At an originating interface, if the ATM virtual connection is a virtual channel connection, then the value contained in octet 6.2 and bits 8-3 of octet 6.3 shall be the same as the 802.14 station's primary local identifier. Otherwise, the user shall clear the call with Cause #100 "Invalid information element contents". b) At a destination interface, if the connection is a point-to-point virtual channel connection (i.e., bits 2-1 of octet 6 of the Broadband Bearer Capability are coded as 'point-to-point'), then the value contained in octet 6.2 and bits 8-3 of octet 6.3 shall be the same as the 802.14 station's primary local identifier; otherwise, the user shall clear the call with Cause #100 "Invalid information element contents". Annex B (Normative) Use of the PHY/MAC-layer identifier in ATM over ADSL Networks One PHY Layer that supports multiple PHY layer identifiers is Asymmetric Digital Subscriber Loops, as specified in ITU 992.1 and ANSI T1.413 [3]. B.1. Background There are two logical paths through the ADSL Physical layer, either of which can be used to carry an ATM virtual connection. The Interleaved Path uses forward error correction with convolutional interleaving to provide robustness against bursts of transmission errors. The interleaving function necessarily adds a large (orders of tens of milliseconds) of fixed delay to the PHY service offered to the ATM layer. The Fast Path omits the interleaving function. Thus, selection of a path to carry an ATM virtual connection effects a tradeoff between the fixed part of maximum cell transfer delay and errored cell ratio and severely errored cell block ratio (see the TM 4.0 specification). In order to permit network policy and the needs of the application to determine this tradeoff, it is necessary to be able to dynamically bind ATM SVCs to one latency channel or the other at the time that they are established. B.2. Use of the PHY/MAC Layer -Identifier procedures B.2.1 Coding of the PHY/MAC-layer identifier The Identifier Value field of octets 6.2 and 6.3 of the PHY/MAC-Connection-identifier information element is coded as specified in section 3.1 to indicate the selected latency paths in the downstream and upstream directions, respectively. B.2.2 Procedures The procedures of section 5 apply to ADSL-based access networks. When a switched VPC service or soft PVPCs are supported over ADSL, then the PHY/MAC-layer identifier negotiation procedures bind the VPC to the latency path. Since the VCI field is carried transparently by a VPC service, any VCCs within the VPC are also bound to that latency path. The latency path in the downstream and upstream is negotiated independently. If negotiation is used, the latency path shall be negotiated in both directions (i.e., both octets 6.2 and 6.3 shall be present), even if the virtual connection has PCR(0+1)=0 in one direction. When either the user or the network or both do not support the negotiation procedures, then the default latency path shall be the interleaved path. Note: The ADSL PHY presents a single PHY service access point (PHY-SAP -- see the UNI 3.1 specification) to the ATM layer. The presence of two latency paths does not imply two instances of the ATM layer entity (e.g., only one set of VPI and VCI values are present at the ADSL UNI). PHY/MAC Identifier AF-CS-0135.000 Addendum to UNI Signaling 4.0 November 1999 Page 24 of 24 ATM Forum Technical Committee