draft-dunbar-6man-5g-edge-compute-sticky-service-01.txt		draft-dunbar-6man-5g-edge-compute-sticky-service-02.txt
	Network Working Group L. Dunbar		Network Working Group L. Dunbar
	Internet Draft J. Kaippallimalil		Internet Draft J. Kaippallimalil
	Intended status: Standard Futurewei		Intended status: Standard Futurewei
	Expires: June 18, 2021		Expires: August 22, 2021
	December 18, 2020		February 22, 2021
	IPv6 Solution for 5G Edge Computing Sticky Service		IPv6 Solution for 5G Edge Computing Sticky Service
	draft-dunbar-6man-5g-edge-compute-sticky-service-01		draft-dunbar-6man-5g-edge-compute-sticky-service-02
	Abstract		Abstract
	This draft describes an IPv6 solution that enables packets from an		This draft describes an IPv6 solution that enables packets from an
	application on a UE (User Equipment) sticking to the same application		application on a UE (User Equipment) sticking to the same ANYCAST
	server location when the UE moves from one 5G cell site to another.		server location when the UE moves from one 5G cell site to another.
			The proposed solution expands the Application-aware ID and Service-
			Para options specified by [APN6] by including the ANYCAST Sticky
			Service location information in the IPv6 Hop-by-Hop or Destination
			Optional Header.
	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.
	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. This document may not be modified,		provisions of BCP 78 and BCP 79. This document may not be modified,
	and derivative works of it may not be created, except to publish it		and derivative works of it may not be created, except to publish it
	as an RFC and to translate it into languages other than English.		as an RFC and to translate it into languages other than English.
	skipping to change at page 1, line 40 ¶		skipping to change at page 2, line 5 ¶
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
			Internet-Draft IPv6 for 5G Edge Sticky Service
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on April 7, 2021.		This Internet-Draft will expire on April 7, 2021.
	Internet-Draft IPv6 for 5G Edge Sticky Service
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction.................................................. 3		1. Introduction.................................................. 3
	1.1. 5G Edge Computing Background.......................... 3		1.1. 5G Edge Computing Background.......................... 3
	1.2. Problem #1: ANYCAST in 5G EC Environment.............. 4		1.2. 5G Edge Computing Network Properties.................. 3
	1.3. Problem #2: sticking to original App Server........... 5		1.3. Problem #1: ANYCAST in 5G EC Environment.............. 5
	1.4. Problem #3: Application Server Relocation............. 5		1.4. Problem #2: sticking to original App Server........... 6
	2. Conventions used in this document............................. 6		1.5. Problem #3: Application Server Relocation............. 6
	3. Sticky Egress node to an ANYCAST Server....................... 7		2. Conventions used in this document............................. 7
	4. End-Node based Sticky Service Solution........................ 8		3. Sticky Egress node to an ANYCAST Server....................... 8
	4.1. Sticky Egress Address Discovery....................... 9		4. End-Node based Sticky Service Solution........................ 9
	4.2. Sticky-Dst-SubTLV in Destination Extension Header.... 10		4.1. Sticky Egress Address Discovery...................... 10
	4.3. Expected behavior at the UE.......................... 11		4.2. Sticky-Dst-SubTLV in Destination Extension Header.... 11
	4.4. Processing at the Ingress router..................... 11		4.3. Expected behavior at the UE.......................... 12
	5. Tunnel based Sticky Service Solutions........................ 12		4.4. Processing at the Ingress router..................... 12
	5.1. Ingress and Egress Routers Processing Behavior....... 12		5. Tunnel based Sticky Service Solutions........................ 13
	5.2. Scenario 1: Without Communication with 5G system..... 14		5.1. Ingress and Egress Routers Processing Behavior....... 13
	5.3. Scenario 2: With communication with 5G system........ 14		5.2. Scenario 1: Without Communication with 5G system..... 15
	6. Manageability Considerations................................. 15		5.3. Scenario 2: With communication with 5G system........ 15
	7. Security Considerations...................................... 15		6. Expanding APN6 for Sticky Service information................ 16
	8. IANA Considerations.......................................... 15		6.1. Sticky Service ID encoded in the Application-aware ID 16
	9. References................................................... 15		6.2. Sticky Service Sub-TLV encoded in APN6 Service-para
	9.1. Normative References................................. 15		option.................................................... 16
	9.2. Informative References............................... 16		7. Manageability Considerations................................. 17
	10. Acknowledgments............................................. 16		8. Security Considerations...................................... 17
			9. IANA Considerations.......................................... 17
	Internet-Draft IPv6 for 5G Edge Sticky Service		Internet-Draft IPv6 for 5G Edge Sticky Service
			10. References.................................................. 17
			10.1. Normative References................................ 17
			10.2. Informative References.............................. 17
			11. Acknowledgments............................................. 18
	1. Introduction		1. Introduction
	1.1. 5G Edge Computing Background		1.1. 5G Edge Computing Background
	As described in [5G-EC-Metrics], one Application in 5G Edge Computing		As described in [5G-EC-Metrics], one Application in 5G Edge Computing
	environment can have multiple Application Servers hosted in different		environment can have multiple Application Servers hosted in different
	Edge Computing data centers that are close in proximity. Those Edge		Edge Computing data centers that are close in proximity. Those Edge
	Computing (mini) data centers are usually very close to, or co-		Computing (mini) data centers are usually very close to, or co-
	located with, 5G base stations, with the goal to minimize latency and		located with, 5G base stations, with the goal to minimize latency and
	optimize the user experience.		optimize the user experience.
	skipping to change at page 4, line 5 ¶		skipping to change at page 3, line 42 ¶
	When the UE moves out of coverage of its current gNB (next generation		When the UE moves out of coverage of its current gNB (next generation
	Node B) (gNB1), handover procedures are initiated and the 5G SMF		Node B) (gNB1), handover procedures are initiated and the 5G SMF
	(Session Management Function) also selects a new UPF-PSA. The		(Session Management Function) also selects a new UPF-PSA. The
	standard handover procedures described in 3GPP TS 23.501 and TS		standard handover procedures described in 3GPP TS 23.501 and TS
	23.502 are followed. When the handover process is complete, the UE		23.502 are followed. When the handover process is complete, the UE
	has a new IP address and the IP point of attachment is to the new		has a new IP address and the IP point of attachment is to the new
	UPF-PSA. 5GC may maintain a path from the old UPF to new the UPF for		UPF-PSA. 5GC may maintain a path from the old UPF to new the UPF for
	a short period of time for SSC [Session and Service Continuity] mode		a short period of time for SSC [Session and Service Continuity] mode
	3 to make the handover process more seamless.		3 to make the handover process more seamless.
			1.2. 5G Edge Computing Network Properties
			In this document, 5G Edge Computing Network refers to multiple
			Local IP Data Networks (LDN) in one region that interconnect
			the Edge Computing mini-data centers. Those IP LDN networks are
			the N6 interfaces from 3GPP 5G perspective.
			The ingress routers to the 5G Edge Computing Network are the
			routers directly connected to 5G UPFs. The egress routers to
			Internet-Draft IPv6 for 5G Edge Sticky Service
			the 5G Edge Computing Network are the routers that have direct
			link to the Edge Computing servers. The servers and the egress
			routers are co-located. Some of those mini Edge Computing Data
			centers may have Virtual switches or Top of Rack switches
			between the egress routers and the servers. But transmission
			delay between the egress routers and the Edge Computing servers
			is so small, therefore can be considered negligible in this
			document.
			When one mini data center has multiple Edge Computing Servers
			attached to one App Layer Load Balancer, only the App Layer
			Load Balancer is visible to the 5G Edge Computing Network. How
			the App Layer Load balancer manages the individual servers is
			out of the scope of the network layer.
			The Edge Computer Services are specially managed services that
			need to utilize the network topology and balance among multiple
			mini Edge Computing Data Centers with the same ANYCAST address.
			UEs can access many services that are not part of the
			registered 5G Edge Computing Services.
	Internet-Draft IPv6 for 5G Edge Sticky Service		Internet-Draft IPv6 for 5G Edge Sticky Service
	+--+		+--+
	|UE|---\+---------+ +------------------+		|UE|---\+---------+ +------------------+
	+--+ | 5G | +---------+ | S1: aa08::4450 |		+--+ | 5G | +---------+ | S1: aa08::4450 |
	+--+ | Site +--++---+ +----+ |		+--+ | Site +--++---+ +----+ |
	|UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 |		|UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 |
	+--+ | +---+---+ +----+ |		+--+ | +---+---+ +----+ |
	+---+ | | | | | S3: aa08::4470 |		+---+ | | | | | S3: aa08::4470 |
	|UE1|---/+---------+ | | +------------------+		|UE1|---/+---------+ | | +------------------+
	skipping to change at page 4, line 36 ¶		skipping to change at page 5, line 36 ¶
	|UE|---\+---------+ | | +------------------+		|UE|---\+---------+ | | +------------------+
	+--+ | 5G | | | | S1: aa08::4450 |		+--+ | 5G | | | | S1: aa08::4450 |
	+--+ | Site +--++-+--+ +----+ |		+--+ | Site +--++-+--+ +----+ |
	|UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 |		|UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 |
	+--+ | +--++----+ +----+ |		+--+ | +--++----+ +----+ |
	+--+ | | +-----------+ | S3: aa08::4470 |		+--+ | | +-----------+ | S3: aa08::4470 |
	|UE|---/+---------+ +------------------+		|UE|---/+---------+ +------------------+
	+--+ L-DN2		+--+ L-DN2
	Figure 1: App Servers in different edge DCs		Figure 1: App Servers in different edge DCs
	1.2. Problem #1: ANYCAST in 5G EC Environment		1.3. Problem #1: ANYCAST in 5G EC Environment
	Increasingly, ANYCAST is used extensively by various application		Increasingly, ANYCAST is used extensively by various application
	providers and CDNs because it is possible to dynamically load balance		providers and CDNs because it is possible to dynamically load balance
	across multiple locations of the same address based on network		across multiple locations of the same address based on network
	conditions. BGP is an integral part in the way IP anycast usually		conditions. BGP is an integral part in the way IP anycast usually
	functions. Within BGP routing there are multiple routes for the same		functions. Within BGP routing there are multiple routes for the same
	IP address which are pointing to different locations.		IP address which are pointing to different locations.
	Application Server location selection using Anycast address leverages		Application Server location selection using Anycast address leverages
	the proximity information present in the network (routing) layer and		the proximity information present in the network (routing) layer and
	skipping to change at page 5, line 18 ¶		skipping to change at page 6, line 18 ¶
	new location.		new location.
	But, having multiple locations for the same ANYCAST address in 5G		But, having multiple locations for the same ANYCAST address in 5G
	Edge Computing environment can be problematic because all those edge		Edge Computing environment can be problematic because all those edge
	computing Data Centers can be close in proximity. There might not be		computing Data Centers can be close in proximity. There might not be
	any difference in the routing cost to reach the Application Servers		any difference in the routing cost to reach the Application Servers
	in different Edge DCs. Same routing cost to multiple ANYCAST		in different Edge DCs. Same routing cost to multiple ANYCAST
	locations can cause packets from one flow to be forwarded to		locations can cause packets from one flow to be forwarded to
	different locations, which can cause service glitches.		different locations, which can cause service glitches.
	1.3. Problem #2: sticking to original App Server		1.4. Problem #2: sticking to original App Server
	When a UE moves to a new location but continues the same application		When a UE moves to a new location but continues the same application
	flow, routers at the new location might choose the App Server closer		flow, routers at the new location might choose the App Server closer
	to the new location. As shown in the figure below, when the UE1 in		to the new location. As shown in the figure below, when the UE1 in
	5G-site-A moves to the 5G-Site-B, the router directly connected to 5G		5G-site-A moves to the 5G-Site-B, the router directly connected to 5G
	PSA2 might forward the packets destined towards the S1: aa08::4450 to		PSA2 might forward the packets destined towards the S1: aa08::4450 to
	the server located in L-DN2 because L-DN2 has the lowest cost based		the server located in L-DN2 because L-DN2 has the lowest cost based
	on routing.		on routing.
	This is not the desired behavior for some services, which are called		This is not the desired behavior for some services, which are called
	skipping to change at page 5, line 44 ¶		skipping to change at page 6, line 44 ¶
	It worth noting that not all services need to be sticky. We assume		It worth noting that not all services need to be sticky. We assume
	only a subset of services are, and the Network is informed of the		only a subset of services are, and the Network is informed of the
	services that need to be sticky, usually by requests from application		services that need to be sticky, usually by requests from application
	developers or controllers.		developers or controllers.
	This document describes an IPv6 based network layer solution to stick		This document describes an IPv6 based network layer solution to stick
	the packets belonging to the same flow of a UE to its original App		the packets belonging to the same flow of a UE to its original App
	Server location after the UE is anchored to a new UPF-PSA.		Server location after the UE is anchored to a new UPF-PSA.
	1.4. Problem #3: Application Server Relocation		1.5. Problem #3: Application Server Relocation
	When an Application Server is added to, moved, or deleted from a 5G		When an Application Server is added to, moved, or deleted from a 5G
	Edge Computing Data Center, the routing protocol has to propagate the		Edge Computing Data Center, the routing protocol has to propagate the
	changes to 5G PSA or the PSA adjacent routers. After the change, the		changes to 5G PSA or the PSA adjacent routers. After the change, the
	cost associated with the site [5G-EC-Metrics] might change as well.		cost associated with the site [5G-EC-Metrics] might change as well.
	Note: for the ease of description, the Edge Computing Server,		Note: for the ease of description, the Edge Computing Server,
	Application Server, or App Server are used interchangeably throughout		Application Server, or App Server are used interchangeably throughout
	this document.		this document.
	Internet-Draft IPv6 for 5G Edge Sticky Service		Internet-Draft IPv6 for 5G Edge Sticky Service
	2. Conventions used in this document		2. Conventions used in this document
			APN6 Application aware network using IPv6. The term
			"Application" has very broad meanings. In this document
			the term "Application" refers to any applications that
			use ANYCAST servers in the 5G Edge Computing
			Environment.
	A-ER: Egress Router to an Application Server, [A-ER] is used		A-ER: Egress Router to an Application Server, [A-ER] is used
	to describe the last router that the Application Server		to describe the last router that the Application Server
	is attached. For 5G EC environment, the A-ER can be the		is attached. For 5G EC environment, the A-ER can be the
	gateway router to a (mini) Edge Computing Data Center.		gateway router to a (mini) Edge Computing Data Center.
	Application Server: An application server is a physical or virtual		Application Server: An application server is a physical or virtual
	server that host the software system for the		server that host the software system for the
	application.		application.
	Application Server Location: Represent a cluster of servers at one		Application Server Location: Represent a cluster of servers at one
	skipping to change at page 6, line 43 ¶		skipping to change at page 8, line 5 ¶
	NOTE: The above terminologies are the same as those used		NOTE: The above terminologies are the same as those used
	in 3GPP TR 23.758		in 3GPP TR 23.758
	Edge DC: Edge Data Center, which provides the Edge Computing Hosting		Edge DC: Edge Data Center, which provides the Edge Computing Hosting
	Environment. It might be co-located with 5G Base Station		Environment. It might be co-located with 5G Base Station
	and not only host 5G core functions.		and not only host 5G core functions.
	gNB next generation Node B		gNB next generation Node B
			Internet-Draft IPv6 for 5G Edge Sticky Service
	L-DN: Local Data Network		L-DN: Local Data Network
	PSA: PDU Session Anchor (UPF)		PSA: PDU Session Anchor (UPF)
	SSC: Session and Service Continuity		SSC: Session and Service Continuity
	Internet-Draft IPv6 for 5G Edge Sticky Service
	UE: User Equipment		UE: User Equipment
	UPF: User Plane Function		UPF: User Plane Function
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 7, line 46 ¶		skipping to change at page 9, line 4 ¶
	address(es). To the LDN's ingress routers, e.g. Ra or Rb in the		address(es). To the LDN's ingress routers, e.g. Ra or Rb in the
	Figure 1, achieving sticky service is to send the packets belonging		Figure 1, achieving sticky service is to send the packets belonging
	to the same flow to the same Sticky Egress node's unicast address.		to the same flow to the same Sticky Egress node's unicast address.
	From Local Data Network perspective, the Sticky Egress nodes' unicast		From Local Data Network perspective, the Sticky Egress nodes' unicast
	addresses are the Next Hops (i.e. R1, R2, and R3) to reach the Edge		addresses are the Next Hops (i.e. R1, R2, and R3) to reach the Edge
	Computing server ANYCAST address.		Computing server ANYCAST address.
	The Flow Affinity feature, which is supported by most commercial		The Flow Affinity feature, which is supported by most commercial
	routers today, can ensure packets belonging to one flow be forwarded		routers today, can ensure packets belonging to one flow be forwarded
			Internet-Draft IPv6 for 5G Edge Sticky Service
	along the same path to the same egress router which then delivers the		along the same path to the same egress router which then delivers the
	packets to the attached Edge Computing Server.		packets to the attached Edge Computing Server.
	Editor's note: for IPv6 traffic, Flow Affinity can be supported by		Editor's note: for IPv6 traffic, Flow Affinity can be supported by
	the routers of the Local Data Network (LDN) forwarding the packets		the routers of the Local Data Network (LDN) forwarding the packets
	with the same Flow Label in the packets' IPv6 Header along the same		with the same Flow Label in the packets' IPv6 Header along the same
	Internet-Draft IPv6 for 5G Edge Sticky Service
	path towards the same egress router. For IPv4 traffic, 5 tuples in		path towards the same egress router. For IPv4 traffic, 5 tuples in
	the IPv4 header can be used to achieve the Flow Affinity		the IPv4 header can be used to achieve the Flow Affinity
	The solution described in this document is to ensure a flow from a UE		The solution described in this document is to ensure a flow from a UE
	to be forwarded to the same egress router of the App Server after the		to be forwarded to the same egress router of the App Server after the
	UE moves to a new 5G Site which result in the UE being assigned a new		UE moves to a new 5G Site which result in the UE being assigned a new
	IP address and attached to a new access router.		IP address and attached to a new access router.
	4. End-Node based Sticky Service Solution		4. End-Node based Sticky Service Solution
	skipping to change at page 8, line 32 ¶		skipping to change at page 9, line 38 ¶
	- There is an EdgeCompute-Controller that can exchange information		- There is an EdgeCompute-Controller that can exchange information
	with the Edge Computing servers.		with the Edge Computing servers.
	- Network is aware of the Sticky Services by the Sticky Service		- Network is aware of the Sticky Services by the Sticky Service
	Identifiers, which can be ANYCAST addresses or regular IP		Identifiers, which can be ANYCAST addresses or regular IP
	addresses. If an Edge Computing service needs to be sticky in		addresses. If an Edge Computing service needs to be sticky in
	the 5G Edge Computing environment, the service ID is registered		the 5G Edge Computing environment, the service ID is registered
	with the 5G Edge Computing controller.		with the 5G Edge Computing controller.
	Here is the overview of the End-Node based Sticky Service solution:		Here is the overview of the End-Node based Sticky Service solution:
	- Each ANYCAST Edge Computing server either learns or is informed		- Each ANYCAST Edge Computing server either learns or is informed
	of the unicast Sticky Egress address (Section 3). The goal of		of the unicast Sticky Egress address (Section 3). The goal of
	the network is to deliver packets belonging to one flow to the		the network is to deliver packets belonging to one flow to the
	same Sticky Egress address for the ANYCAST address. Section 4.1		same Sticky Egress address for the ANYCAST address. Section 4.1
	describes how Edge Computing Servers discover their		describes how Edge Computing Servers discover their
	corresponding Sticky Egress unicast addresses.		corresponding Sticky Egress unicast addresses.
	- When an Edge Computing server sends data packets to a UE (or		- When an Edge Computing server sends data packets to a UE (or
	client), it inserts the Sticky-Dst-SubTLV (described in Section		client), it inserts the Sticky-Dst-SubTLV (described in Section
	4.2) into the packets' Destination Option Header.		4.2) into the packets' Destination Option Header.
	- UE (or client) needs to copy the Destination Option Header from		- UE (or client) needs to copy the Destination Option Header from
	the received packet to the next packet's Destination Header if		the received packet to the next packet's Destination Header if
	the next packet belongs to the same flow as the previous packet.		the next packet belongs to the same flow as the previous packet.
			Internet-Draft IPv6 for 5G Edge Sticky Service
	- If the following conditions are true, the ingress router		- If the following conditions are true, the ingress router
	encapsulates the packet from the UE in a tunnel whose outer		encapsulates the packet from the UE in a tunnel whose outer
	destination address is set to the Sticky Egress Address		destination address is set to the Sticky Egress Address
	extracted from the packet's Sticky-Dst-SubTLV:		extracted from the packet's Sticky-Dst-SubTLV:
	Internet-Draft IPv6 for 5G Edge Sticky Service
	o The destination of the packet from the UE side matches		o The destination of the packet from the UE side matches
	with one of the Sticky Service ACLs configured on the		with one of the Sticky Service ACLs configured on the
	ingress router of the LDN,		ingress router of the LDN,
	o the packet header has the Destination Option present with		o the packet header has the Destination Option present with
	Sticky-Dst-SubTLV.		Sticky-Dst-SubTLV.
	- Else (i.e. one of the conditions above is not true), the ingress		- Else (i.e. one of the conditions above is not true), the ingress
	node uses its own algorithm, such as the least cost as described		node uses its own algorithm, such as the least cost as described
	in [5G-EC-Metrics], to select the optimal Sticky Egress address		in [5G-EC-Metrics], to select the optimal Sticky Egress address
	for forwarding the packet.		for forwarding the packet.
	skipping to change at page 15, line 18 ¶		skipping to change at page 16, line 18 ¶
	connected to the new PSA.		connected to the new PSA.
	Upon receiving the entry, the ingress router merges the entry into		Upon receiving the entry, the ingress router merges the entry into
	its own Sticky-Service-Table.		its own Sticky-Service-Table.
	The ingress and egress router processing are the same as described in		The ingress and egress router processing are the same as described in
	Section 5.1 except a flow is now uniquely identified by the "Sticky		Section 5.1 except a flow is now uniquely identified by the "Sticky
	Service ID" + "UE address" instead of "Sticky Service ID" + "Flow		Service ID" + "UE address" instead of "Sticky Service ID" + "Flow
	Label".		Label".
	6. Manageability Considerations		6. Expanding APN6 for Sticky Service information
			The Application-aware ID and Service-Para Option described
			[APN6] can be expanded to include the sticky service
			information.
			6.1. Sticky Service ID encoded in the Application-aware ID
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sticky Level |StickyServiceID| Reserved | Flow ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Sticky Level: represent how important for an application to stick to
			its ANYCAST servers. Some applications may prefer one flow sticking
			to the original ANYCAST server, but not required. Some applications
			may require the stickiness.
			StickyServiceID: the ANYCAST address of the application servers.
			The Reserved field can be used for future to identifier the 5G access
			domain for the flow.
			Flow ID: the identifier for the flow that needs to stick to a
			specific ANYCAST server.
			6.2. Sticky Service Sub-TLV encoded in APN6 Service-para option
			The Sticky-Dst-SubTLV described in the Section 4.2 of this document
			can be included in the Service-Para Sub-TLVs field.
			Internet-Draft IPv6 for 5G Edge Sticky Service
			7. Manageability Considerations
	To be added.		To be added.
	7. Security Considerations		8. Security Considerations
	To be added.		To be added.
	8. IANA Considerations		9. IANA Considerations
	To be added.		To be added.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private networks		[RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private networks
	(VPNs)", Feb 2006.		(VPNs)", Feb 2006.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
	Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May		Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
	2017, <https://www.rfc-editor.org/info/rfc8174>.		2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 (IPv6)		[RFC8200] s. Deering R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", July 2017		Specification", July 2017
	Internet-Draft IPv6 for 5G Edge Sticky Service		10.2. Informative References
	9.2. Informative References
	[3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation Partnership		[3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation Partnership
	Project; Technical Specification Group Services and System		Project; Technical Specification Group Services and System
	Aspects; Study on enhancement of support for Edge		Aspects; Study on enhancement of support for Edge
	Computing in 5G Core network (5GC)", Release 17 work in		Computing in 5G Core network (5GC)", Release 17 work in
	progress, Aug 2020.		progress, Aug 2020.
	[5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP Layer		[5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP Layer
	Metrics for 5G Edge Computing Service", draft-dunbar-ippm-		Metrics for 5G Edge Computing Service", draft-dunbar-ippm-
	5g-edge-compute-ip-layer-metrics-00, work-in-progress, Oct		5g-edge-compute-ip-layer-metrics-00, work-in-progress, Oct
	2020.		2020.
			Internet-Draft IPv6 for 5G Edge Sticky Service
			[APN6] Z. Li, et al, "Application-aware IPv6 Networking (APN6)
			Encapsulation", draft-li-6man-app-aware-ipv6-network-03,
			work-in-progress, Feb 2021.
	[RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent		[RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent
	Address Family Identifier (SAFI) and the BGP Tunnel		Address Family Identifier (SAFI) and the BGP Tunnel
	Encapsulation Attribute", April 2009.		Encapsulation Attribute", April 2009.
	[BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension for SDWAN		[BGP-SDWAN-Port] L. Dunbar, H. Wang, W. Hao, "BGP Extension for SDWAN
	Overlay Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext-		Overlay Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext-
	03, work-in-progress, Nov 2018.		03, work-in-progress, Nov 2018.
	[SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. Majumdar,		[SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. Majumdar,
	"BGP UPDATE for SDWAN Edge Discovery", draft-dunbar-idr-		"BGP UPDATE for SDWAN Edge Discovery", draft-dunbar-idr-
	sdwan-edge-discovery-00, work-in-progress, July 2020.		sdwan-edge-discovery-00, work-in-progress, July 2020.
	[Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation		[Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation
	Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018.		Attribute", draft-ietf-idr-tunnel-encaps-10, Aug 2018.
	10. Acknowledgments		11. Acknowledgments
	Acknowledgements to Ron Bonica and Donald Eastlake for their review		Acknowledgements to Ron Bonica and Donald Eastlake for their review
	and contributions.		and contributions.
	This document was prepared using 2-Word-v2.0.template.dot.		This document was prepared using 2-Word-v2.0.template.dot.
	Internet-Draft IPv6 for 5G Edge Sticky Service
	Authors' Addresses		Authors' Addresses
	Linda Dunbar		Linda Dunbar
	Futurewei		Futurewei
	Email: ldunbar@futurewei.com		Email: ldunbar@futurewei.com
	John Kaippallimalil		John Kaippallimalil
	Futurewei		Futurewei
	Email: john.kaippallimalil@futurewei.com		Email: john.kaippallimalil@futurewei.com
End of changes. 30 change blocks.
	51 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/