x50-20090615-0xx zte vsp proposal 1 title: 3gpp2 specific vendor specific protocol sources: zte...

X50-20090615-0xx ZTE VSP Proposal

1

Title: 3GPP2 Specific Vendor Specific Protocol

Sources: ZTE

Contact: Rajesh Bhalla ([email protected])

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.


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


RFC3772 Based 3GPP2 VSP FrameworkHigh 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


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

UE eAN/ ePCF HSGW P-GW hPCRF

2 . Map information provided in PCC Rules to

eHRPD specific format

vPCRF

Roaming Scenario

(Y ) eHRPD Access Specific mechanisms to enforce the UE-APN Aggregate Parameters

10. Gateway Control and QoS Policy Rules Provision - end

1 . Gateway Control and QoS Policy Rules and Provision - begin

11. PCC Rules Provision Procedure

3. VSP Configure-Request (APN and APN-AMBR Configuration Options ...)

4. VSP Configure-Ack (APN and APN-AMBR Configuration Options ...)


Different VSP ApproachesDiscussions

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


VSP Based on RFC2153 FrameworkSome 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

Code Identifier Length

Magic Number

OUI Kind

0 7 8 15 16 23 24 31

Value(s)


VSP Based on RFC3772 FrameworkSome 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


VSP Based on RFC3772 FrameworkSome 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


RFC2153 Vs RFC3772 VSPProtocol 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


RFC2153 vs RFC3772 VSPApproach 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


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

x50-20090615-0xx zte vsp proposal 1 title: 3gpp2 specific vendor specific protocol sources: zte...

Documents