X xx ZTE VSP Proposal 1 Title: 3GPP2 Specific Vendor Specific Protocol Sources: ZTE Contact: Rajesh Bhalla ABSTRACT: Extensible mechanisms based on IETF recommendations are needed to allow for the exchange of configuration and/or operational parameters between the UE and the HSGW at any time during IP-CAN sessions. Such parameters may pertain to a protocol layer above LCP. Such parameters may also pertain to a single IP-CAN session, or to several/all IP-CAN sessions Recommendation: Review and adopt ZTE grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. ZTE is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by ZTE to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on contributors. ZTE specifically reserves the right to amend or modify the material contained herein and to any intellectual property of contributors other than provided in the copyright statement above.

X xx ZTE VSP Proposal 2 Introduction  Background 3GPP2 VSNCP and VSNP protocols (as specified in X.S0057) are based on the PPP Vendor Protocol framework defined in RFC3772 VSNCP and VSNP are 3GPP2 proprietary network control and network protocols, defined to meet eHRPD access network specific requirements for eHRPD – E- UTRAN Interworking RFC3772 provides another protocol, the Vendor Specific Protocol (VSP – Protocol Number 0x405b) VSP is intended for use in situations where per-link signaling is required  The Proposal The proposal is to adopt RFC3772 recommended framework for 3GPP2 Vendor Specific Protocol (VSP) (Protocol Number – 0x405b) RFC2153 specifies another framework for PPP Vendor Extensions. That framework, however, is not well suited for the requirements specific to eHRPD – E- UTRAN Interworking Per the proposed RFC3372 recommended VSP framework in this contribution and the accompanying protocol detailed contribution: once the underlying PPP session has been established and peer entities authenticated (if so required), either the UE and/or the HSGW can initiate the exchange of the necessary parameters by the use of VSP protocol

X xx ZTE VSP Proposal RFC3772 Based 3GPP2 VSP Framework High Level Description  The proposed 3GPP2 VSP is based on the VSP framework in RFC3772 (Protocol Number 0x405b)  The proposed 3GPP2 VSP provides a mechanism for peer-to-peer signaling between the UE and the HSGW for the exchange of necessary parameters  Such 3GPP2 VSP signaling does not impact LCP and/or other network layer protocols (viz. VSNCP and VSNP) and is applicable to the data-link between the UE and the HSGW  3GPP2 VSP uses the same packet exchange and option extension mechanisms as LCP specified in RFC1661, but with a different set of options  One 3GPP2 VSP packet is carried in the PPP Information field, with the Protocol field set to 0x405b  Once the underlying PPP session has been established and peer entities authenticated (if so required), 3GPP2 VSP signaling can be performed at any time. Per the proposed 3GPP2 VSP framework:  Either the UE and/or the HSGW can initiate the exchange of required parameters by the use of a VSP Configure-Request packet  On successful processing of the VSP Configure-Request packet, the receiving entity responds with a VSP Configure-Ack packet

X xx ZTE VSP Proposal Example 3GPP2 VSP Packet Exchange  The figure below illustrates an example high level HSGW initiated parameter exchange procedure based on the proposed 3GPP2 Vendor Specific Protocol

X xx ZTE VSP Proposal Different VSP Approaches Discussions  RFC2153 and RFC3772 provide two different approaches for PPP extensions  Some of the differences in the two approaches include the Protocol Number and the packet format  X.S0011-D adopted VSP packet based on RFC2153  However, we chose RFC3772 for 3GPP2 VSNCP and 3GPP2 VSNP  We could have achieved similar VSNCP and VSNP functionality by using RFC2153 VSP framework though  Rightly – we did not use RFC2153 framework for 3GPP2 VSNCP and 3GPP2 VSNP, as RFC3772 addresses some of the problems in RFC2153 based approach !!  RFC2153 VSP exchange happens at LCP level, and there could/would be parameters exchanged between the UE and the HSGW that do not belong to the LCP layer  (Just to mention, most of the parameters exchanged between the UE and the PDSN in X.S0011-D by use of RFC2153 VSP do not belong to the LCP layer)  RFC3772 provides a method that addresses the problems that have been identified for the RFC2153 VSP approach  From that perspective: RFC3772 mentions about the problems with using RFC2153 extensions. Notably :  RFC2153 VSP happens at LCP layer, hence the exchange of the parameters could begin before identification and authentication of the peer has been done  The use of non-standardized protocol number/Kind values for parameter exchange is not conducive to the development of efficient diagnostic mechanisms. Having an IANA specified fixed number for VSP provides a reasonable diagnostic approach  In addition (though not in RFC3772), the exchange of the parameters that do not belong to LCP, at LCP layer (in RFC2153 approach) is a protocol-layer violation

X xx ZTE VSP Proposal VSP Based on RFC2153 Framework Some Details  The ‘Protocol’ field is set to: 0xC021  LCP ‘Information’ field contains Vendor Specific Packet (VSP) with Code= ‘0’  3GPP2 specific ‘Kind’ values are defined for the exchange of different parameters between the UE and the PDSN  Based on the ‘Kind’ value, a different set of additional parameters (Values) can be defined  Value(s) field is customized to be vendor specific  No standardized approach for the format of the Value(s) field has been defined

X xx ZTE VSP Proposal VSP Based on RFC3772 Framework Some Details  The ‘Protocol’ field is set to: 0x405b  The ‘Information’ field contains one packet with the format below  The ‘Data’ field is customized to be vendor specific

X xx ZTE VSP Proposal VSP Based on RFC3772 Framework Some Details (contd..)  The proposal is to standardize the format of the ‘Data’ field to be similar to the LCP Packet Format (RFC1661)  Having defined LCP-similar packet format, extensions for carrying the ‘parameters’ are defined by inheriting the format of LCP ‘Configuration Options’ (RFC1661)  Similar to RFC1661, ‘Code’ values are proposed for Configure-Request, Configure-Ack and Configure-Reject VSP packets to enable the exchange of parameters between the UE and the HSGW  (Any other names for the packets could be chosen for achieving similar functionality)  All of the above is similar and intuitive to the framework adopted for the definition of 3GPP2 VSNCP protocol

X xx ZTE VSP Proposal RFC2153 Vs RFC3772 VSP Protocol Framework  RFC2153  Extensions for exchanging new parameter types are defined by defining new ‘Kind’ values  ‘Kind’ values are defined for every new parameter that needs to be exchanged  The behavior and associated response for a VSP packet is based on the ‘Kind’ value  As new ‘Kind’ values are defined, associated behavior needs to be defined as well  This definition of the behavior for every ‘Kind’ value is in addition to the definition of the method for the handling of the associated parameters exchanged (within the Values field)  RFC3772  A new protocol number (0x405b) makes the need for defining ‘behavior’ for every new type of parameter exchanged not necessary  By defining generic behavior for supported ‘Code’ values (request, ack, reject packets etc.), definition of the behavior for handling the packet for every new type of parameter exchanged not necessary  The behavior for handling of the packets with the identified ‘Code’ values is inherited from PPP framework (RFC1661)  With that done in the baseline 3GPP2 VSP framework, the extensions for new parameter types are defined with the definition of Configuration Options for new parameters that need to be exchanged.  This framework and extension mechanisms align with the approach used for other protocols as well (e.g., PPP, VSNCP, etc.)  In summary; for defining extensions for new parameter types:  RFC2153 framework needs definition of new ‘Kind’ values, description of the behavior for packets with new ‘Kind’ values, the description of new associated parameters (within the Value field) and the associated behavior for handling new parameters  RFC3772 framework needs definition of new Configuration Options (for new parameters to be exchanged) and the associated behavior for handling the new parameters

X xx ZTE VSP Proposal RFC2153 vs RFC3772 VSP Approach Used  No protocol-layer violations with RFC3772 based framwork  The currently identified parameters that need to be exchanged between the UE and the HSGW have nothing to do with the LCP-layer  A protocol-layer violation-proof method is used for VSP based parameter exchange  RFC2153 defined VSP packet can still be used if some parameter(s) specific to LCP are identified for exchange between the UE and the HSGW  No exchange of parameters till the peer has been identified and authenticated  X.S0011-D VSP procedures do not state of any such restrictions/limitations on the exchange of LCP based VSP packets  That is not to say that such classification/limitations cannot be added at this stage or in the future  Doing so would make LCP based VSP implementation much fuzzy though  We would not want to say that certain ‘Kind’ of VSP packets cannot be exchanged till LCP negotiations and the (next level) of authentication has been completed, whereas other ‘Kind’ of VSP packets have no such restrictions  Whereas, with RFC3772 based approach, such VSP exchange happens only past-PPP establishment and authentication phase

X xx ZTE VSP Proposal Proposal and Recommendations  In summary; for defining extensions for new parameter types:  RFC2153 framework needs definition of new ‘Kind’ values, description of the behavior for packets with new ‘Kind’ values, the description of new associated parameters (within the Value field) and the associated behavior for handling new parameters  Whereas, RFC3772 framework needs definition of new Configuration Options (for new parameters to be exchanged) and the associated behavior for handling the new parameters  No protocol-layer violations with the RFC3772 based approach  RFC2153 based VSP can be used for the exchange of LCP related parameters (as and when identified)  No parameter exchange till the peer has been identified and authorized (if authorization required)  IANA specified protocol number for VSP; assuring industry and IETF support (in the future) and also for matters such as standardized diagnostic tools etc.  The recommendation, therefore, is to adopt RFC3772 VSP framework for the definition of 3GPP2 Vendor Specific Protocol for eHRPD deployments