Le 31/01/2018 à 22:14, Sri Gundavelli (sgundave) a écrit :
Based on the feedback and some offline discussions with Danny and others,
here is the response with some corrections. Please comment.
------------------------------------
Dear 3GPP SA2 Chair:
Thank you for your LS query (Reference:
https://datatracker.ietf.org/liaison/1554/). The IETF DMM working group
has reviewed the LS statement and below is our response.
In our view, the work-item described in the LS query has three components:
1.) The approach of coloring IPv4 and IPv6 addresses/prefixes with
mobility properties.
This is about standardizing IP address address/prefix ³types". Each ³type"
has a certain behavior that the network is expected to provide. Section
3.1, of draft-ietf-dmm-ondemand-mobility-13 defines the following four
address types, which are applicable to both IPv4 and IPv6 addresses and
prefixes.
#a. Fixed IP Address
#b. Session-lasting IP Address
#c. Non-persistent IP Address
#d. Graceful Replacement IP Address
These modes, #a, #b, #c,and #d can be mapped to the 3GPP SSC modes 1, 2
and 3.
We are happy to report that this work-item is on track to become an
³informational standard", and will most likely will hit IESG very soon.
We kindly request 3GPP to provide any feedback that you may have on this
draft.
2.) The approach of network including property meta-data in address
assignment procedures
There are multiple mechanisms for address configuration delivery to the
end-host:
#a.) DHCPv4
#b.) DHCPv6
#c.) IPv6 ND (PIO Options, others ..etc)
#d.) IKEv2 Address Configuration Options
There are many proposals on this including:
https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt
https://www.ietf.org/id/draft-moses-dmm-dhcp-ondemand-mobility-08.txt
Also, some proposals from the previous years:
https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-ndp-support-03.txt
https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-id-02.txt
https://www.ietf.org/archive/id/draft-bhandari-dhc-class-based-prefix-05.txt
I propose you add the following draft about ND Prefix Delegation
extensions to Neighbor Discovery:
https://tools.ietf.org/html/draft-kaiser-nd-pd-01
(it is not about coloring the prefix, but it is about prefix delegation
options in ND)
Alex
...
Currently, these documents are under review in the IETF DMM WG. However,
the DMM working group has not chosen any specific draft as WG document.
Given the interest from 3GPP for this work, we will try to accelerate the
document selection process and will try to move this work forward. This is
subject to finding consensus for taking up this work.
We also like to point out that, all though the LS statement explicitly
refers to both IPv4 and IPv6 address types, however it only mentions about
(RA) (IPv6 ND implied) as the mechanism for address property delivery. It
is to be noted that the approach of delivering coloring meta-data in RA
messages will most likely be to limited to IPv6 address/prefix types and
will not be extended to IPv4 addresses. If this capability is required for
IPv4, we may have to possibly extend DHCP protocol(s).
We kindly request SA2 to clarify if the Ask is explicitly for IPv6, or if
its for both IPv4 and IPv6 address/prefix types.
3.) The approach of indicating the coloring meta-data to the applications
on the mobile node (UE in 3GPP terminology).
This is about extending socket interface with the property tags. This is
covered in draft-ietf-dmm-ondemand-mobility-13,
We are happy to report that this work is on track to become an
³informational standard", and will most likely will hit IESG very soon.
We kindly request 3GPP to provide any feedback that you may have on this
draft.
Regards
Dapeng Liu and Sri Gundavelli
(Chairs IETF DMM Working Group)
-----------------------------------------------------------
On 1/16/18, 2:45 PM, "Liaison Statement Management Tool"
<[email protected]>
wrote:
Title: LS on indicating service continuity usage of the additional
IPv6
prefix in Router Advertisement
Submission Date: 2018-01-16
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1554/
From: Chang hong <[email protected]>
To: Sri Gundavelli <[email protected]>,Dapeng Liu
<[email protected]>,Terry Manderson
<[email protected]>,Suresh
Krishnan <[email protected]>,Robert Hinden <[email protected]>,Ole
Troan <[email protected]>
Cc: Dapeng Liu <[email protected]>,Terry Manderson
<[email protected]>,IPv6 Maintenance Discussion List
<[email protected]>,Ole Troan <[email protected]>,Sri Gundavelli
<[email protected]>,The IETF Chair <[email protected]>,Robert Hinden
<[email protected]>,Distributed Mobility Management Discussion
List
<[email protected]>,Suresh Krishnan <[email protected]>
Response Contacts: [email protected],[email protected]
Technical Contacts:
Purpose: For information
Body: 1. Overall Description:
3GPP working group SA2 (System Architecture) would like to inform the
IETF that SA2 has defined three SSC (Session and Service Continuity)
modes in 3GPP TS 23.501 ("Architecture for the 5G System") clause
5.6.9
as follows:
- With SSC mode 1, the network preserves the connectivity service
provided to the UE. For the case of PDU Session of IPv4 or IPv6 type,
the
IP address is preserved.
- With SSC mode 2, the network may release the connectivity
service
delivered to the UE and release the corresponding PDU Session. For
the
case of IPv4 or IPv6 type, the network may release IP address(es)
that
had been allocated to the UE.
- With SSC mode 3, changes to the user plane can be visible to
the
UE,
while the network ensures that the UE suffers no loss of
connectivity.
A
connection through new PDU Session Anchor point is established before
the
previous connection is terminated in order to allow for better
service
continuity. For the case of IPv4 or IPv6 type, the IP address is not
preserved in this mode when the PDU Session Anchor changes.
SA2 has also adopted the use of IPv6 multi-homing in a PDU Session
(referred to as "multi-homed IPv6 PDU Session") as described in 3GPP
TS
23.501 clause 5.6.4.3, a PDU Session being an association between the
UE
and a Data Network that provides a data connectivity service, which
is
also defined in 3GPP TS 23.501.
When a new IPv6 Prefix is assigned to the UE for a multi-homed IPv6
PDU
Session, SA2 has decided to use the Router Advertisement message
according to IETF RFC 4191 to deliver the new IPv6 prefix to the UE
and
configure the Routing Rules in the UE by using the Route Information
Option.
SA2 is looking for a mechanism to deliver information regarding the
service continuity usage (e.g. whether the prefix can be replaced
with
or
without grace period) associated with the new IPv6 prefix to the UE
via
the 5G System user plane.
SA2 understands that the IETF draft
"draft-ietf-dmm-ondemand-mobility-12"
defines four IP address types that can be mapped to the three SSC
modes
as follows:
- SSC mode 1 corresponds to either FIXED or SESSION_LASTING;
- SSC mode 2 corresponds to NON_PERSISTENT;
- SSC mode 3 corresponds to GRACEFUL_REPLACEMENT.
SA2 would like to understand if there is any IETF work related to
delivery of the IP address type (according to IETF draft
"draft-ietf-dmm-ondemand-mobility-12") in the Router Advertisement
message, which could be used for delivery of the service continuity
usage
associated with a new IPv6 prefix in a multi-homed IPv6 PDU Session.
2. Actions:
To IETF Internet Area, DMM, 6MAN:
ACTION: SA2 respectfully asks IETF Internet Area, DMM and 6MAN
to
provide feedback on any IETF work related to delivery of IP address
type
(according to IETF draft "draft-ietf-dmm-ondemand-mobility-12") in
the
Router Advertisement message.
3. Date of Next SA2 Meetings:
3GPPSA2#125 OR 22 - 26 Jan 2018 Gothenburg SE
3GPPSA2#126 OR 26 Feb - 2 Mar 2018 US US
Attachments:
S2-179625_e-mail_rev2_S2-179363_LS_out_to_IETF_Internet_Area_DMM_6MAN
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3gpp
-
t
sg
s
a-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the-a
d
d
it
i
onal-ipv6-prefix-in-router-advertisement-attachment-1.doc
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
