< draft-ietf-netext-pmip6-qos-02.txt		draft-ietf-netext-pmip6-qos-02-CEP.txt >
	skipping to change at page 1, line 21		skipping to change at page 1, line 21
	S. Gundavelli		S. Gundavelli
	Cisco		Cisco
	February 25, 2013		February 25, 2013
	Quality of Service Option for Proxy Mobile IPv6		Quality of Service Option for Proxy Mobile IPv6
	draft-ietf-netext-pmip6-qos-02.txt		draft-ietf-netext-pmip6-qos-02.txt
	Abstract		Abstract
	This specification defines a new mobility option that can be used by		This specification defines a new mobility option that can be used by
	the mobility entities in the Proxy Mobile IPv6 domain to exchange		the mobility entities [LMA and MAG] in the Proxy Mobile IPv6 domain to exchange
	Quality of Service parameters associated with a subscriber's IP		Quality of Service parameters associated with a subscriber's IP
	flows. Using the QoS option, the local mobility anchor and the		flows. Using the QoS option, the local mobility anchor and the
	mobile access gateway can exchange available QoS attributes and		mobile access gateway can exchange available QoS attributes and
	associated values. This enables QoS policing and labeling of packets		associated values. This enables QoS policing and labeling of packets
	to enforce QoS differentiation on the path between the local mobility		to enforce QoS differentiation on the path between the local mobility
	anchor and the mobile access gateway. Furthermore, making QoS		anchor and the mobile access gateway. Furthermore, making QoS
	parameters available on the MAG enables mapping these parameters to		parameters available on the MAG enables mapping these parameters to
	QoS rules being specific to the access technology which operates		QoS rules that are specific to the access technology which operates
	below the mobile access gateway. After such mapping, QoS rules can		below the mobile access gateway. After such mapping, QoS rules can
	be enforced on the access technology components, such as an IEEE		be enforced on the access technology components, such as an IEEE
	802.11e Wireless LAN controller.		802.11e Wireless LAN controller.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 5, line 10		skipping to change at page 5, line 10
	Appendix B. Information when implementing with a Broadband		Appendix B. Information when implementing with a Broadband
	Network Gateway . . . . . . . . . . . . . . . . . . . 34		Network Gateway . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to		Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to
	enable network-based mobility management for mobile nodes (MN).		enable network-based mobility management for mobile nodes (MN).
	Users can access Internet Protocol (IP) based services from their		Users can access Internet Protocol (IP) based services from their
	mobile device by using different radio access technologies. Current		mobile device by using various radio access technologies. Current
			<different than what??>
	standardization effort considers strong QoS classification and		standardization effort considers strong QoS classification and
	enforcement for cellular radio access technologies. QoS policies are		enforcement for cellular radio access technologies. QoS policies are
	typically controlled by a policy control function, whereas the		typically controlled by a policy control function, whereas the
	policies are enforced by different gateways in the infrastructure,		policies are enforced by one or more gateways in the infrastructure,
	such as the LMA and the MAG, as well as by access network elements.		such as the LMA and the MAG, as well as by access network elements.
	Policy control and QoS differentiation for access to the mobile		Policy control and QoS differentiation for access to the mobile
	operator network through alternative non-cellular access technologies		operator network through alternative non-cellular access technologies
			CEP: Abstract emphasizes 802.11e == non-cellular
	is not yet considered, even though some of these access technologies		is not yet considered, even though some of these access technologies
	are able to support QoS by appropriate traffic prioritization		are able to support QoS by appropriate traffic prioritization
	techniques. However, handover and IP Flow Mobility using alternative		techniques. However, handover and IP Flow Mobility using alternative
	radio access technologies, such as IEEE802.16 and Wireless LAN		radio access technologies, such as IEEE802.16 and Wireless LAN
	according to the IEEE802.11 specification, are being considered by		according to the IEEE802.11 specification, are being considered by
	the standards [TS23.402], whereas inter-working with the cellular		the standards [TS23.402], whereas inter-working with the cellular
	architecture to establish QoS policies in alternative access networks		architecture to establish QoS policies in alternative access networks
	has not been focussed on so far.		has not gotten much attention so far.
			Does "non-cellular" == alternative access network?
	In particular the Wireless LAN technology has been identified as		In particular Wireless LAN has been identified as a
	promising alternative technology to complement cellular radio access.		promising alternative technology to complement cellular radio access.
	Since the 802.11e standard provides QoS extensions to WLAN, it is		Since the 802.11e standard provides QoS extensions to WLAN, it is
	beneficial to apply QoS policies to the WLAN access, which enables		beneficial to apply QoS policies to WLAN access, which enables
	QoS classification of downlink as well as uplink traffic between an		QoS classification of downlink as well as uplink traffic between an
	MN and its LMA. Three functional operations have been identified to		MN and its LMA. Three functional operations have been identified to
	accomplish this:		accomplish this:
	(a) Maintenance of QoS classification during a handover between		(a) Maintenance of QoS classification during a handover between
	cellular radio access and WLAN access by means of establishing QoS		cellular radio access and WLAN access by means of establishing QoS
	policies in the handover target access network,		policies in the handover target access network,
	(b) mapping of QoS classes and associated policies between		(b) mapping of QoS classes and associated policies between
	different access systems and		different access systems and
	(c) establishment of QoS policies for new data sessions/flows,		(c) establishment of QoS policies for new data sessions/flows,
	which are initiated while using WLAN access.		which are initiated while using WLAN access.
			CEP: need to explain why only one direction is important
	This document specifies an extension to the PMIPv6 protocol, which		This document specifies an extension to the PMIPv6 protocol[citation], which
	enables the transport of established QoS descriptions between an LMA		enables the transport of established QoS descriptions between an LMA
			CEP: established --> standardized?
	and the MAG by means of a QoS container option in case the QoS policy		and the MAG by means of a QoS container option in case the QoS policy
			CEP: what is a "container" option??
	in the WLAN access is not under explicit control of a policy control		in the WLAN access is not under explicit control of a policy control
			CEP: This is not the only scenario for use of the option!
	system. The specified option allows association between IP session		system. The specified option allows association between IP session
			CEP: session key is an undefined term, put in Terminology...
	keys, such as a Differentiated Services Code Point (DSCP), and the		keys, such as a Differentiated Services Code Point (DSCP), and the
	expected QoS class for this IP session. Further handling of QoS		expected QoS class for this IP session. Further handling of QoS
	policies between the MAG and the WLAN Controller (WLC) or WLAN Access		policies between the MAG and the WLAN Controller (WLC) or WLAN Access
	Point is out of scope of this specification.		Point is out of scope of this specification.
	2. Conventions and Terminology		2. Conventions and Terminology
	2.1. Conventions		2.1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 8, line 13		skipping to change at page 8, line 13
	is typically tunneled to this centralized WLAN access controller.		is typically tunneled to this centralized WLAN access controller.
	3. Description of the Technical Approach		3. Description of the Technical Approach
	3.1. Technical Scope and Procedure		3.1. Technical Scope and Procedure
	The QoS option specified in this document supports the setup of		The QoS option specified in this document supports the setup of
	states on the LMA and the MAG to allow enforcement of QoS policies		states on the LMA and the MAG to allow enforcement of QoS policies
	for packet differentiation on the network path between the LMA and		for packet differentiation on the network path between the LMA and
	the MAG providing non-cellular access to the mobile operator network.		the MAG providing non-cellular access to the mobile operator network.
			CEP: Why doesn't it work for packet differentiation on any network?
	QoS differentiation is typically enabled in the mobile operator's		QoS differentiation is typically enabled in the mobile operator's
	network using Differentiated Services techniques in the IP transport		network using Differentiated Services techniques in the IP transport
	network, whereas radio access specific QoS differentiation depends on		network, whereas radio access specific QoS differentiation depends on
	the radio technology in use. Whereas very accurate and fine granular		the radio technology in use. Whereas very accurate and fine granular
	traffic classes are specified for the cellular radio access, the IP		traffic classes are specified for the cellular radio access, the IP
	transport network only supports enforcement of few Differentiated		transport network only supports enforcement of few Differentiated
	Services classes according to well-known Differentiated Services Code		Services classes according to well-known Differentiated Services Code
	Points (DSCP) [GSMA.IR.34].		Points (DSCP) [GSMA.IR.34].
	Central control from a Policy Control Function (PCF) is deployed in		Central control from a Policy Control Function (PCF) is deployed in
	skipping to change at page 8, line 44		skipping to change at page 8, line 45
	Figure 1 illustrates a generalized architecture where the QoS option		Figure 1 illustrates a generalized architecture where the QoS option
	can be used. During an MN's handover from cellular access to non-		can be used. During an MN's handover from cellular access to non-
	cellular access, e.g. a wireless LAN (WLAN) radio access network, the		cellular access, e.g. a wireless LAN (WLAN) radio access network, the
	MN's QoS policy rules, as previously established on the LMA for the		MN's QoS policy rules, as previously established on the LMA for the
	MN's communication through the cellular access network, are moved to		MN's communication through the cellular access network, are moved to
	the handover target MAG serving the non-cellular access network.		the handover target MAG serving the non-cellular access network.
	Such non-cellular MAG can have an access technology specific		Such non-cellular MAG can have an access technology specific
	controller or function co-located, e.g. a Wireless LAN Controller		controller or function co-located, e.g. a Wireless LAN Controller
	(WLC), as depicted in option (I) of Figure 1. Alternatively, the		(WLC), as depicted in option (I) of Figure 1. Alternatively, the
	access specific architecture can be distributed and the access		access specific architecture can be distributed and the access
	technology specific control function is not co-located with the MAG,		technology specific control function located external to the MAG,
	as depicted in option (II). In case of a distributed access network		as depicted in option (II). In case of a distributed access network
	architecture as per option (II), the MAG and the access technology		architecture as per option (II), the MAG and the access technology
	specific control function (e.g. the WLC) must provide some protocol		specific control function (e.g. the WLC) must provide some protocol
	for QoS inter-working. Details of such inter-working are out of		for QoS inter-working. Details of such inter-working are out of
	scope of this specification.		scope of this specification.
	Non-cellular access | Cellular Core Network Cellular		Non-cellular access | Cellular Core Network Cellular
	(e.g. WLAN) | +--------+ Access		(e.g. WLAN) | +--------+ Access
	| |Policy |		| |Policy |
	| |Control +-----+		| |Control +-----+
	skipping to change at page 9, line 32		skipping to change at page 9, line 32
	|WiFi+----+ WLC +------+ (MAG) |=|=======//		|WiFi+----+ WLC +------+ (MAG) |=|=======//
	| AP | | | | | |		| AP | | | | | |
	+----+ +------+ +------ + |		+----+ +------+ +------ + |
	^ ^ |		^ ^ |
	| | |		| | |
	+------------+		+------------+
	QoS inter-working		QoS inter-working
	Figure 1: Architecture for QoS inter-working between cellular access		Figure 1: Architecture for QoS inter-working between cellular access
	and non-cellular access		and non-cellular access
			CEP: what is "((0))"? is it a base station?
	Based on the architecture illustrated in Figure 1, two key use cases		Based on the architecture illustrated in Figure 1, two key use cases
	can be supported by the QoS option. Use case A assumes a MN is		can be supported by the QoS option. Use case A assumes a MN is
	attached to the network through cellular access and its LMA has QoS		attached to the network through cellular access and its LMA has QoS
	policy rules for the MN's data flows available. This specification		policy rules for the MN's data flows available. This specification
	does not depend on the approach how the cellular specific QoS		does not depend on the approach how the cellular specific QoS
	policies have been configured on the LMA. During its handover, the		policies have been configured on the LMA. During its handover, the
	available QoS policies are established on the handover target MAG,		available QoS policies are established on the handover target MAG,
	which serves the non-cellular access network. Use case B assumes		which serves the non-cellular access network. Use case B assumes
	that new policies need to be established for a MN as a new IP flow is		that new policies need to be established for a MN as a new IP flow is
	skipping to change at page 10, line 31		skipping to change at page 10, line 31
	V +----+ +-------+ PMIPv6 //		V +----+ +-------+ PMIPv6 //
	+--+ |WiFi|_______| WLC |=========		+--+ |WiFi|_______| WLC |=========
	|MN|~~| AP | | (MAG) | tunnel		|MN|~~| AP | | (MAG) | tunnel
	+--+ +----+ +-------+		+--+ +----+ +-------+
	Figure 2: Handover Scenario		Figure 2: Handover Scenario
	3.3. Use Case B -- Establishment of new QoS Context in non-3G Access		3.3. Use Case B -- Establishment of new QoS Context in non-3G Access
	A single operator has deployed both a fixed access network and a		A single operator has deployed both a fixed access network and a
			CEP: need to define fixed access network and mobile access network
	mobile access network. In this scenario, the operator may wish a		mobile access network. In this scenario, the operator may wish a
	harmonized QoS management on both accesses. However the fixed access		harmonized QoS management on both accesses, but the fixed access
	network does not implement a QoS control framework. So, the operator		network does not implement a QoS control framework. So, the operator
	chooses to rely on the 3GPP policy control function, which is a		chooses to rely on the 3GPP policy control function, which is a
	standard framework to provide a QoS control, and to enforce the 3GPP		standard framework to provide a QoS control, and to enforce the 3GPP
	QoS policy to the Wi-Fi Access network. The PMIP interface is used		QoS policy on the Wi-Fi Access network. The PMIP interface is used
	to realize this QoS policy provisioning.		to realize this QoS policy provisioning.
	The use-case is depicted on Figure 3. The MN is first attaching to		The use-case is depicted on Figure 3. The MN first attaches to
	the Wi-Fi network. During attachment process, the LMA, which may be		the Wi-Fi network. During the attachment process, the LMA, which may
	in communication with Policy Control Function (this step of the		communicate with Policy Control Function (using procedures
	process is out of the scope of this document), provides the QoS		outside the scope of this document), provides the QoS
	parameters to the MAG piggy-backing the PMIP signaling (i.e. PBA).		parameters to the MAG in an extension to the PMIP signaling (i.e. PBA).
	Subsequently, an application on the MN may trigger the request for		Subsequently, an application on the MN may trigger the request for
	enhanced QoS resources, e.g., by use of the WMM-API [80211e]. The MN		alternate QoS resources, e.g., by use of the WMM-API [80211e]. The MN
	may request traffic resources be reserved using L2 signalling, e.g.,		may request traffic resources be reserved using L2 signalling, e.g.,
	sending an ADDTS message [80211e]. The request is relayed to the MAG		sending an ADDTS message [80211e]. The request is relayed to the MAG
	which piggybacks the QoS parameters on the PMIP signalling (i.e. PBU		which includes the QoS parameters on the PMIP signalling (i.e. the PBU
	initiated on the flow creation). The LMA, in co-ordination with the		initiated upon flow creation). The LMA, in co-ordination with the
	PCF, can then authorize the enforcement of such QoS policy. Then,		PCF, can then authorize the enforcement of such QoS policy. Then,
	the QoS parameters are provided to the MAG piggy-backing the PMIP		the QoS parameters are provided to the MAG as part of the PMIP
	signaling and the equivalent QoS treatment is provided towards the MN		signaling and the equivalent QoS treatment is provided towards the MN
	on the WiFi link.		on the WiFi link.
	|		|
	|		|
	| +--------+		| +--------+
	| |Policy |		| |Policy |
	| |Control |		| |Control |
	| |Function|		| |Function|
	| +---+----+		| +---+----+
	skipping to change at page 11, line 38		skipping to change at page 11, line 38
	|		|
	Figure 3: QoS policy provisioning		Figure 3: QoS policy provisioning
	3.4. Use Case C -- Dynamic Update to QoS Policy		3.4. Use Case C -- Dynamic Update to QoS Policy
	A mobile node is attached to the WLAN access and has obtained QoS		A mobile node is attached to the WLAN access and has obtained QoS
	parameters from the LMA for that mobility session. Having obtained		parameters from the LMA for that mobility session. Having obtained
	the QoS parameters, a new application, e.g. IMS application, gets		the QoS parameters, a new application, e.g. IMS application, gets
	launched on the mobile node that requires certain QoS support.		launched on the mobile node that requires certain QoS support.
			CEP: it is likely that the application launch initiates
			the request for QoS support, not the other way around
	The application on the mobile node initiates the communications via a		The application on the mobile node initiates the communications via a
	dedicated network function (e.g. IMS Call Session Control Function).		dedicated network function (e.g. IMS Call Session Control Function).
	Once the communication is established, the application network		Once the communication is established, the application network
	function notifies the PCRF function about the new IP flow. The PCRF		function notifies the PCRF function about the new IP flow. The PCRF
	function in turn notifies the LMA about the needed QoS parameters		function in turn notifies the LMA about the needed QoS parameters
	identifying the IP flow and QoS parameters. LMA sends a Update		identifying the IP flow and QoS parameters. LMA sends a Update
	Notification message [I-D.ietf-netext-update-notifications] to the		Notification message [I-D.ietf-netext-update-notifications] to the
	MAG with the "Notification Reason" value set to "Force REREGISTER".		MAG with the "Notification Reason" value set to "Force REREGISTER".
			CEP: Is this specific to the scenario, or does the QoS
			extension require use of the notification <I hope not>?
	The MAG, on receiving the Update Notification message, completes the		The MAG, on receiving the Update Notification message, completes the
	PBU/PBA signaling for obtaining the new QoS parameters. MAG		PBU/PBA signaling for obtaining the new QoS parameters. The MAG
	provisions the newly obtained QoS parameters on the access network to		provisions the newly obtained QoS parameters on the access network to
	ensure the newly established IP flow gets some dedicated network		ensure the newly established IP flow gets its requested network
	resources. Upon termination of the new flow, the application network		resources. Upon termination of the new flow, the application network
	function again notifies the PCRF function for removing the		function again notifies the PCRF function for removing the
	established bearers. The PCRF notifies the LMA for withdrawing the		established bearers. The PCRF notifies the LMA for withdrawing the
	QoS resources establishes for that voice flow. LMA sends a Update		QoS resources establishes for that voice flow. The LMA sends a Update
			CEP: "IMS" != "voice"
	Notification message to the MAG with the "Notification Reason" value		Notification message to the MAG with the "Notification Reason" value
	set to "Force REREGISTER". MAG on receiving this message		set to "Force REREGISTER". MAG on receiving this message
	UpdateNotification Ack and completes the PBU/PBA signaling for		UpdateNotification Ack and completes the PBU/PBA signaling for
	obtaining the new QoS parameters. MAG provisions the newly obtained		obtaining the new QoS parameters. MAG provisions the newly obtained
	QoS parameters on the access network to ensure the dedicated network		QoS parameters on the access network to ensure the dedicated network
	resources are now removed.		resources are now removed.
	3.5. Relevant QoS Attributes		3.5. Relevant QoS Attributes
	The QoS Option shall at least contain a DSCP value being associated		The QoS Option shall at least contain a DSCP value being associated
	skipping to change at page 12, line 37		skipping to change at page 12, line 38
	2. Per mobility session Aggregate Maximum Bit Rate (MS-AMBR) to both		2. Per mobility session Aggregate Maximum Bit Rate (MS-AMBR) to both
	uplink and downlink directions.		uplink and downlink directions.
	The following attributes represent a useful set of QoS parameters to		The following attributes represent a useful set of QoS parameters to
	negotiate during the session setup:		negotiate during the session setup:
	1. Allocation and Retention Priority (ARP).		1. Allocation and Retention Priority (ARP).
	2. Guaranteed Bit Rate (GBR)		2. Guaranteed Bit Rate (GBR)
			CEP: This acronym is only used once, and probably should not appear
	3. Maximum Bit Rate (MBR)		3. Maximum Bit Rate (MBR)
			CEP: This acronym is never used
	For some optional QoS attributes the signaling can differentiate		For some optional QoS attributes the signaling can differentiate
	enforcement per mobility session and per IP flow. Additional		enforcement per mobility session and per IP flow. Additional
	attributes can be appended to the QoS option, but their definition		attributes can be appended to the QoS option, but their definition
	and specification is out of scope of this document and left to their		and specification is out of scope of this document and left to their
	actual deployment.		actual deployment.
			CEP: I don't see how the contents of the QoS option could
			be left outside of the specification for the QoS option.
	Informational Note: If DSCP values follow the 3GPP specification and		Informational Note: If DSCP values follow the 3GPP specification and
	deployment, the code point can carry intrinsically additional		deployment, the code point can carry intrinsically additional
	attributes according to a pre-defined mapping table:		attributes according to a pre-defined mapping table:
	This is the GSMA/3GPP mapping for EPC/LTE:		This is the GSMA/3GPP mapping for EPC/LTE:
	QCI Traffic Class DiffServ PHB DSCP		QCI Traffic Class DiffServ PHB DSCP
	1 Conversational EF 101110		1 Conversational EF 101110
	2 Conversational EF 101110		2 Conversational EF 101110
	skipping to change at page 16, line 27		skipping to change at page 16, line 27
	the mobility session or to the mobile node. Specifically, the		the mobility session or to the mobile node. Specifically, the
	following parameters must be defined.		following parameters must be defined.
	1. Flow Selectors (if QoS parameters are expected to apply at the		1. Flow Selectors (if QoS parameters are expected to apply at the
	flow level)		flow level)
	2. DSCP Value		2. DSCP Value
	3. List of QoS parameters encoded in TLV format		3. List of QoS parameters encoded in TLV format
	If a mobile access gateway is enabled to support Quality of Service		If a mobile access gateway is enabled to support the Quality of Service
	option, upon accepting a Proxy Binding Acknowledgement with Quality		CEP: Probably should use "MAG" in this section...
			option, upon accepting a Proxy Binding Acknowledgement with a Quality
	of Service option, it SHOULD update the Binding Update List for that		of Service option, it SHOULD update the Binding Update List for that
	mobility session with the quality of service parameters received from		mobility session with the quality of service parameters received from
	the local mobility anchor. However, if the mobile access gateway is		the local mobility anchor. However, if the mobile access gateway is
	not enabled to support Quality of Service option, it SHOULD just skip		not enabled to support Quality of Service option, it SHOULD just skip
	the option and continue to process the rest of the message.		the option and continue to process the rest of the message.
			CEP: skippable option number...
	The mobility access gateway SHOULD enforce the Quality of Service		The mobility access gateway SHOULD enforce the Quality of Service
	rules on the mobile node's uplink and downlink traffic as notified by		rules on the mobile node's uplink and downlink traffic as notified by
	the local mobility anchor. The traffic selectors in the received		the local mobility anchor. The traffic selectors in the received
	Quality of Service option are to be used for the flow identification.		Quality of Service option are to be used for the flow identification.
	The DSCP field in the option along with the other parameters in the		The DSCP field in the option along with the other parameters in the
	QoS Information field are to be used for the flow treatment.		QoS Information field are to be used for the flow treatment.
	In deployments where the mobile access gateway is collocated with a		In deployments where the mobile access gateway is collocated with a
	WLAN controller, there is interworking needed between the two		WLAN controller, interworking is needed between the two
	functions for exchanging the Quality of Service parameters. The WLAN		functions for exchanging the Quality of Service parameters. The WLAN
	controller can potentially deliver the Quality of Service parameters		controller can potentially deliver the Quality of Service parameters
	to the Access Point/WTP over CAPWAP or other control protocol		to the Access Point/WTP over CAPWAP or other control protocol
	interface. The specific details on how that is achieved is outside		interface. The specific details on how that is achieved is outside
	the scope of this document.		the scope of this document.
	4.2. Local Mobility Anchor Considerations		4.2. Local Mobility Anchor Considerations
	The conceptual Binding Cache entry data structure maintained by the		The conceptual Binding Cache entry data structure maintained by the
	local mobility anchor, described in Section 5.1 of [RFC5213], MUST be		local mobility anchor, described in Section 5.1 of [RFC5213], MUST be
	skipping to change at page 17, line 29		skipping to change at page 17, line 29
	Upon accepting a Proxy Binding Update message [RFC5213] from a mobile		Upon accepting a Proxy Binding Update message [RFC5213] from a mobile
	access gateway, and if the local mobility anchor is enabled to		access gateway, and if the local mobility anchor is enabled to
	enforce the Quality of Service rules, it SHOULD construct the Quality		enforce the Quality of Service rules, it SHOULD construct the Quality
	of Service mobility option and include it in the Proxy Binding		of Service mobility option and include it in the Proxy Binding
	Acknowledgement message.		Acknowledgement message.
	The Quality of Service MUST be constructed as specified in Section 5.		The Quality of Service MUST be constructed as specified in Section 5.
	The flow selectors and the parameters for flow treatment MUST be		The flow selectors and the parameters for flow treatment MUST be
	included in the option only if QoS policy is expected to apply at the		included in the option only if QoS policy is expected to apply at the
	flow level.		flow level.
			CEP: reword?
	The local mobility anchor SHOULD enforce the Quality of Service rules		The local mobility anchor SHOULD enforce the Quality of Service rules
	on the mobile node's uplink and downlink traffic as specified for		on the mobile node's uplink and downlink traffic as specified for
	that mobility session.		that mobility session.
			CEP: why not MUST, if the request did not generate an error?
	5. Quality of Service Option		5. Quality of Service Option
	A new option, Quality of Service option, is defined for use with a		A new option, Quality of Service option, is defined for use with a
	Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA)		Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA)
	messages exchanged between a local mobility anchor and a mobile		messages exchanged between a local mobility anchor and a mobile
	access gateway. This option is used for providing QoS policies and		access gateway. This option is used for providing QoS policies and
	information to the mobile access gateway.		information to the mobile access gateway.
	The alignment requirement for this option is 4n.		The alignment requirement for this option is 4n.
	skipping to change at page 19, line 8		skipping to change at page 19, line 8
	o DSCP: An 6-bit unsigned integer indicating the code point value,		o DSCP: An 6-bit unsigned integer indicating the code point value,
	as defined in [RFC2475] to be used for the flow.		as defined in [RFC2475] to be used for the flow.
	o QoS Information: one or more Type-Length-Value (TLV) encoded QoS		o QoS Information: one or more Type-Length-Value (TLV) encoded QoS
	policies. The interpretation and usage of the QoS information is		policies. The interpretation and usage of the QoS information is
	specific to the TLV.		specific to the TLV.
	6. Format of the Quality of Service Attribute		6. Format of the Quality of Service Attribute
	The QoS Attribute are used for carrying QoS policy attributes. These		The QoS Attribute are used for carrying QoS policy attributes. These
	sub-options can be included in the QoS option defined in Section 5.		suboptions can be included in the QoS option defined in Section 5.
	The format of this sub-option is as follows.		The format of this suboption is as follows.
			CEP: Should reorganize the TLVs so that the Traffic Selector
			(section 6.8) comes before the QoS constraints
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Option Data ~		| Type | Length | Option Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: Quality of Service Attribute		Figure 7: Quality of Service Attribute
	QoS Attribute Type: 8-bit unsigned integer indicating the type of		QoS Attribute Type: 8-bit unsigned integer indicating the type of
	skipping to change at page 19, line 36		skipping to change at page 19, line 39
	2 - Per Mobile Node Aggregate Maximum Uplink Bit Rate		2 - Per Mobile Node Aggregate Maximum Uplink Bit Rate
	3 - Per Mobility Session Aggregate Maximum Downlink Bit Rate		3 - Per Mobility Session Aggregate Maximum Downlink Bit Rate
	4 - Per Mobility Session Aggregate Maximum Uplink Bit Rate		4 - Per Mobility Session Aggregate Maximum Uplink Bit Rate
	5 - Allocation and Retention Priority		5 - Allocation and Retention Priority
	6 - Traffic Selector		6 - Traffic Selector
			CEP: Guaranteed Downlink Bit Rate is missing.
	7 - Guaranteed Uplink Bit Rate		7 - Guaranteed Uplink Bit Rate
	Length: 8-bit unsigned integer indicating the number of octets		Length: 8-bit unsigned integer indicating the number of octets
	needed to encode the Option Data, excluding the Type and Length		needed to encode the Option Data, excluding the Type and Length
	fields.		fields.
			CEP: Do these correspond with 3GPP definitions?
			CEP: What about definitions from other SDOs?
			CEP: Nothing about latency, jitter...
	6.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate		6.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate
	The maximum downlink bit rate for a single Mobile Node. The maximum		This is the maximum downlink bit rate for a single Mobile Node. The maximum
	is an aggregate of all mobility session the Mobile Node has. When		is an aggregate of all the Mobile Node's mobility sessions. When
	provided in a request, it indicates the maximum requested bandwidth.		provided in a request, it indicates the maximum requested bandwidth.
	When provided in an answer, it indicates the maximum bandwidth		When provided in an acknowledgement, it indicates the maximum bandwidth
	accepted.		accepted.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Max-Bandwidth-DL |		| Max-Bandwidth-DL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 21, line 22		skipping to change at page 21, line 22
	o Type: 3		o Type: 3
	o Length: The length of following data value in octets. Set to 6.		o Length: The length of following data value in octets. Set to 6.
	o Max-Requested-Bandwidth-DL: is of type unsigned 32 bit integer,		o Max-Requested-Bandwidth-DL: is of type unsigned 32 bit integer,
	and it indicates the maximum bandwidth in bits per second for a		and it indicates the maximum bandwidth in bits per second for a
	downlink IP flow. The bandwidth contains all the overhead coming		downlink IP flow. The bandwidth contains all the overhead coming
	from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP		from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP
	payload.		payload.
			CEP: How is the session identified??
	6.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate		6.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate
	The maximum uplink bit rate for a single specific mobility session		The maximum uplink bit rate for a single specific mobility session
	the Mobile Node has. When provided in a request, it indicates the		the Mobile Node has. When provided in a request, it indicates the
	maximum requested bandwidth. When provided in an answer, it		maximum requested bandwidth. When provided in an answer, it
	indicates the maximum bandwidth accepted.		indicates the maximum bandwidth accepted.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at page 21, line 46		skipping to change at page 21, line 47
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Type: 4		o Type: 4
	o Length: The length of following data value in octets. Set to 6.		o Length: The length of following data value in octets. Set to 6.
	o Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it		o Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it
	indicates the maximum bandwidth in bits per second for an uplink		indicates the maximum bandwidth in bits per second for an uplink
	IP flow. The bandwidth contains all the overhead coming from the		IP flow. The bandwidth contains all the overhead coming from the
	IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.		IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.
			CEP: How is the session identified??
	6.5. Allocation and Retention Priority		6.5. Allocation and Retention Priority
	The allocation and retention priority indicate the priority of		The allocation and retention priority indicates the priority of
	allocation and retention for the corresponding mobility session or		allocation and retention for the corresponding mobility session or
	flow. If the attribute is expected to apply at the flow level, the		flow. If the attribute is expected to apply at the flow level, the
	traffic selector (Section 6.8) MUST be included in the QoS option.		traffic selector (Section 6.8) MUST be included in the QoS option.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Priority-Level |		| Priority-Level |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Pre-emption-Capability | Pre-emption-Vulnerability |		| Pre-emption-Capability | Pre-emption-Vulnerability |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Type: 5		o Type: 5
	o Length: The length of following data values in octets. Set to 10.		o Length: The length of following data values in octets. Set to 10.
	o Priority-Level: is of type unsigned 32 bit integer, and it used		o Priority-Level: is of type unsigned 32 bit integer, and it is used
	for deciding whether a mobility session establishment or		to decide whether a mobility session establishment or
	modification request can be accepted or needs to be rejected in		modification request can be accepted or needs to be rejected
	case of resource limitations (typically used for admission control		(typically used for admission control of GBR traffic in case of
	of GBR traffic). The priority-level can also be used to decide		resource limitations). The priority level can also be used to
	which existing mobility session to pre-empt during resource		decide which existing mobility session to pre-empt during resource
	limitations. The priority level defines the relative importance		limitations. The priority level defines the relative timeliness
	of a resource request.		of a resource request.
			CEP:
			CEP: Some preemptible flows are more important than some
			non-preemptible flows.
	Values 1 to 15 are defined, with value 1 as the highest level of		Values 1 to 15 are defined, with value 1 as the highest level of
	priority.		priority.
	Values 1 to 8 should only be assigned for services that are		Values 1 to 8 should only be assigned for services that are
	authorized to receive prioritized treatment within an operator		authorized to receive prioritized treatment within an operator
	domain. Values 9 to 15 may be assigned to resources that are		domain. Values 9 to 15 may be assigned to resources that are
	authorized by the home network and thus applicable when a MN is		authorized by the home network and thus applicable when a MN is
	roaming.		roaming.
			CEP: Why is this a 32-bit field? It could easily fit in the
			"Reserved" field...
			CEP: Not clear why all operator services are always prioritized
			over all external services...
	o Pre-emption-Capability: defines whether a service data flow can		o Pre-emption-Capability: defines whether a service data flow can
	get resources that were already assigned to another service data		get resources that were already assigned to another service data
	flow with a lower priority level. The following values are		flow with a lower priority level. The following values are
	defined:		defined:
	Enabled (0): This value indicates that the service data flow is		Enabled (0): This value indicates that the service data flow is
	allowed to get resources that were already assigned to another IP		allowed to get resources that were already assigned to another IP
	data flow with a lower priority level.		data flow with a lower priority level.
	Disabled (1): This value indicates that the service data flow is		Disabled (1): This value indicates that the service data flow is
	not allowed to get resources that were already assigned to another		not allowed to get resources that were already assigned to another
	IP data flow with a lower priority level.		IP data flow with a lower priority level.
			CEP: Not clear why this flag polarity was chosen, seems opposite
			of the natural definition.
	o Pre-emption-Vulnerability: defines whether a service data flow can		o Pre-emption-Vulnerability: defines whether a service data flow can
	lose the resources assigned to it in order to admit a service data		lose the resources assigned to it in order to admit a service data
	flow with higher priority level. The following values are		flow with higher priority level. The following values are
	defined:		defined:
	Enabled (0): This value indicates that the resources assigned to		Enabled (0): This value indicates that the resources assigned to
	the IP data flow can be pre-empted and allocated to a service data		the IP data flow can be pre-empted and allocated to a service data
	flow with a higher priority level.		flow with a higher priority level.
	Disabled (1): This value indicates that the resources assigned to		Disabled (1): This value indicates that the resources assigned to
	the IP data flow shall not be pre-empted and allocated to a		the IP data flow shall not be pre-empted and allocated to a
	service data flow with a higher priority level.		service data flow with a higher priority level.
			CEP: Not clear why this flag polarity was chosen, seems opposite
			of the natural definition.
			CEP: Needs to be specified that "Vulnerability" setting
			"pre-empts" the "Capability" setting.
	6.6. Guaranteed Downlink Bit Rate		6.6. Guaranteed Downlink Bit Rate
	The guaranteed downlink bit rate for a specific flow or mobility		The guaranteed downlink bit rate for one of the Mobile Node's
	session the Mobile Node has. When provided in a request, it		specific flows or mobility sessions. When provided in a request, it
	indicates the maximum requested bandwidth. When provided in an		indicates the maximum bandwidth requested. When provided in an
	answer, it indicates the maximum bandwidth accepted.		answer, it indicates the maximum bandwidth allocated.
	If the attribute is expected to apply at the flow level, the traffic		If the attribute is expected to apply at the flow level, the traffic
	selector (Section 6.8) MUST be included in the QoS option.		selector (Section 6.8) MUST be included in the QoS option.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Guaranteed-DL |		| Guaranteed-DL |
	skipping to change at page 25, line 15		skipping to change at page 25, line 15
	7. IANA Considerations		7. IANA Considerations
	This document requires the following IANA actions.		This document requires the following IANA actions.
	o Action-1: This specification defines a new Mobility Header option,		o Action-1: This specification defines a new Mobility Header option,
	the Quality of Service (QoS) option. The format of this option is		the Quality of Service (QoS) option. The format of this option is
	described in Section 5. The Type value for this option needs to		described in Section 5. The Type value for this option needs to
	be assigned from the same numbering space as allocated for the		be assigned from the same numbering space as allocated for the
	other mobility options, as defined in [RFC6275].		other mobility options, as defined in [RFC6275].
	o Action-2: This specification defines a new mobility sub-option		o Action-2: This specification defines a new mobility suboption
	format,Quality of Service Attribute. The format of this mobility		format,Quality of Service Attribute. The format of this mobility
	sub-option is described in Section 6. This sub-option can be		suboption is described in Section 6. This suboption can be
	carried in Quality of Service option. The type values for this		carried in Quality of Service option. The type values for this
	sub-option needs to be managed by IANA, under the Registry,		suboption needs to be managed by IANA, under the Registry,
	Quality of Service Attribute Registry. This specification		Quality of Service Attribute Registry. This specification
	reserves the following type values. Approval of new Quality of		reserves the following type values. Approval of new Quality of
	Service Attribute type values are to be made through IANA Expert		Service Attribute type values are to be made through IANA Expert
	Review.		Review.
	0 - Reserved		0 - Reserved
	1 - Per Mobile Node Aggregate Maximum Downlink Bit Rate		1 - Per Mobile Node Aggregate Maximum Downlink Bit Rate
	2 - Per Mobile Node Aggregate Maximum Uplink Bit Rate		2 - Per Mobile Node Aggregate Maximum Uplink Bit Rate
	skipping to change at page 27, line 4		skipping to change at page 26, line 13
	7 - Guaranteed Uplink Bit Rate		7 - Guaranteed Uplink Bit Rate
	8. Security Considerations		8. Security Considerations
	The quality of service option defined in this specification is for		The quality of service option defined in this specification is for
	use in Proxy Binding Update and Proxy Binding Acknowledgement		use in Proxy Binding Update and Proxy Binding Acknowledgement
	messages. This option is carried like any other mobility header		messages. This option is carried like any other mobility header
	option as specified in [RFC5213] and does not require any special		option as specified in [RFC5213] and does not require any special
	security considerations. Carrying quality of service information		security considerations. Carrying quality of service information
	does not introduce any new security vulnerabilities.		does not introduce any new security vulnerabilities.
			CEP: This isn't true. Asking for high priority can have the
			effect of starving unrelated flows from other
			devices. That's a security vulnerability.
	9. Acknowledgements		9. Acknowledgements
	The authors of this document thank the NetExt Working Group for the		The authors of this document thank the NetExt Working Group for the
	valuable feedback on early versions of this document. In particular		valuable feedback on early versions of this document. In particular
	the authors want to thank Basavaraj Patil, Behcet Sarikaya, Charles		the authors want to thank Basavaraj Patil, Behcet Sarikaya, Charles
	Perkins, Dirk von Hugo, Mark Grayson and Tricci So for their valuable		Perkins, Dirk von Hugo, Mark Grayson and Tricci So for their valuable
	comments and suggestions to improve this specification.		comments and suggestions to improve this specification.
	10. References		10. References
End of changes. 55 change blocks.
	47 lines changed or deleted		95 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/