< draft-bernardos-dmm-sfc-mobility-03.txt   draft-bernardos-dmm-sfc-mobility-04.txt >
SFC WG CJ. Bernardos SFC WG CJ. Bernardos
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Experimental A. Mourad Intended status: Experimental A. Mourad
Expires: March 14, 2022 InterDigital Expires: 22 September 2022 InterDigital
September 10, 2021 21 March 2022
SFC function mobility with Mobile IPv6 SFC function mobility with Mobile IPv6
draft-bernardos-dmm-sfc-mobility-03 draft-bernardos-dmm-sfc-mobility-04
Abstract Abstract
Service function chaining (SFC) allows the instantiation of an Service function chaining (SFC) allows the instantiation of an
ordered set of service functions and subsequent "steering" of traffic ordered set of service functions and subsequent "steering" of traffic
through them. In order to set up and maintain SFC instances, a through them. In order to set up and maintain SFC instances, a
control plane is required, which typically is centralized. In control plane is required, which typically is centralized. In
certain environments, such as fog computing ones, such centralized certain environments, such as fog computing ones, such centralized
control might not be feasible, calling for distributed SFC control control might not be feasible, calling for distributed SFC control
solutions. This document specifies Mobile IPv6 extensions to enable solutions. This document specifies Mobile IPv6 extensions to enable
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 14, 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Function mobility signaling extending Mobile IPv6 . . . . . . 5 3. Function mobility signaling extending Mobile IPv6 . . . . . . 5
4. Mobile IPv6 extensions for SFC function mobility . . . . . . 7 4. Mobile IPv6 extensions for SFC function mobility . . . . . . 6
4.1. Service Path Update . . . . . . . . . . . . . . . . . . . 7 4.1. Service Path Update . . . . . . . . . . . . . . . . . . . 6
4.2. Service Path Acknowledgement . . . . . . . . . . . . . . 9 4.2. Service Path Acknowledgement . . . . . . . . . . . . . . 8
4.3. New Mobility options . . . . . . . . . . . . . . . . . . 10 4.3. New Mobility options . . . . . . . . . . . . . . . . . . 9
4.3.1. Network Service ID . . . . . . . . . . . . . . . . . 10 4.3.1. Network Service ID . . . . . . . . . . . . . . . . . 9
4.3.2. SFC node . . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. SFC node . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Virtualization of functions provides operators with tools to deploy Virtualization of functions provides operators with tools to deploy
new services much faster, as compared to the traditional use of new services much faster, as compared to the traditional use of
monolithic and tightly integrated dedicated machinery. As a natural monolithic and tightly integrated dedicated machinery. As a natural
next step, mobile network operators need to re-think how to evolve next step, mobile network operators need to re-think how to evolve
their existing network infrastructures and how to deploy new ones to their existing network infrastructures and how to deploy new ones to
address the challenges posed by the increasing customers' demands, as address the challenges posed by the increasing customers' demands, as
well as by the huge competition among operators. All these changes well as by the huge competition among operators. All these changes
skipping to change at page 6, line 11 skipping to change at page 5, line 19
management operation: the update of the location of a given function. management operation: the update of the location of a given function.
We refer to this as function mobility, though it might involve or not We refer to this as function mobility, though it might involve or not
the actual migration of the function. the actual migration of the function.
+---------+ +----+ +---------+ +---------+ +----------+ +------+ +---------+ +----+ +---------+ +---------+ +----------+ +------+
| node A | | C | | node B | | node D | | 3GPP | | SFC | | node A | | C | | node B | | node D | | 3GPP | | SFC |
|P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL| |P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL|
+--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+ +--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+
| | | | | | | | | | | | | | | | | |
| F1@A<->F2@B<->F3@D SFC network service | | | F1@A<->F2@B<->F3@D SFC network service | |
| |<-.-.-.-.-.-.-.-.-.>|<-.-.-.-.->| | | | |<-·-·-·-·-·-·-·-·-·>|<-·-·-·-·->| | |
| | | | | | | | | | | | | | | | | |
| | | Node B moves out of | | | | | Node B moves out of | |
| | | the coverage of node D | | | | | the coverage of node D | |
| | | | | | | | | | | | | | | | | |
| 0. Service specific OAM monitoring | | | | 0. Service specific OAM monitoring | | |
|<-.>|<-.-.->|<-.-.-.-.-.>| | | | | |<-·>|<-·-·->|<-·-·-·-·-·>| | | | |
|<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·->| |
| | | | | | | | | | | | | | | | | |
P-CTRL@A detects D disconnection | | | | P-CTRL@A detects D disconnection | | | |
and decides to place F3 at node C | | | | and decides to place F3 at node C | | | |
| | | | | | | | | | | | | | | | | |
| 1a. SPU[NS_ID,(F3,C)] | | | | | | 1a. SPU[NS_ID,(F3,C)] | | | | |
|-.-.-.-.-.-.-.-.-.-.-.-.>| | | | | |-·-·-·-·-·-·-·-·-·-·-·-·>| | | | |
| 1b. SPA[NS_ID] | | | | | | 1b. SPA[NS_ID] | | | | |
|<-.-.-.-.-.-.-.-.-.-.-.-.| | | | | |<-·-·-·-·-·-·-·-·-·-·-·-·| | | | |
| 1c. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | | | 1c. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | |
|-.-.-.-.-.->| | | | | | | |-·-·-·-·-·->| | | | | | |
| 1d. SPA[NS_ID] | | | | | | | 1d. SPA[NS_ID] | | | | | |
|<-.-.-.-.-.-| | | | | | | |<-·-·-·-·-·-| | | | | | |
| | | | | | | | | | | | | | | | | |
| 2. Updated F1@A<->F2@B<->F3@C SFC network service | | 2. Updated F1@A<->F2@B<->F3@C SFC network service |
| |<-.-.-.-.-.-.-.-.-.>| | | | | | |<-·-·-·-·-·-·-·-·-·>| | | | |
| | |<-.-.-.-.-.>| | | | | | | |<-·-·-·-·-·>| | | | |
| | | | | | | | | | | | | | | | | |
| 3a. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | | 3a. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | |
|-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·->|
| | | | | | | 3b. SPA[NS_ID] | | | | | | | | 3b. SPA[NS_ID] |
|<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-|
| 3c. SPU[NS_ID,(F3,C)] | | | | | | 3c. SPU[NS_ID,(F3,C)] | | | | |
|-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| | | |-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·>| | |
| | | | 3d. SPA[NS_ID] | | | | | | | 3d. SPA[NS_ID] | | |
|<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-|
| | | | | | | | | | | | | | | | | |
Figure 1: SFC mobility signaling
Figure 1: SFC mobility signaling
We next describe the signaling extensions with an example. For the We next describe the signaling extensions with an example. For the
sake of this example we assume that the function which location is sake of this example we assume that the function which location is
updated is already available at the new target node (if not, it has updated is already available at the new target node (if not, it has
to be previously migrated using any of the solutions available in the to be previously migrated using any of the solutions available in the
state-of-the-art). The different steps are described next: state-of-the-art). The different steps are described next:
o (The network service F1--F2--F3 is already instantiated and * (The network service F1--F2--F3 is already instantiated and
running. The only SFC P-CTRL active at this point is running at running. The only SFC P-CTRL active at this point is running at
node A, and there is a candidate one at node B.) node A, and there is a candidate one at node B.)
o UE node B is moving out of the coverage of gNB node D. * UE node B is moving out of the coverage of gNB node D.
1. This movement is detected by the active (designated) pseudo 1. This movement is detected by the active (designated) pseudo
controller running at node A, thanks to local (service specific controller running at node A, thanks to local (service specific
OAM) monitoring. OAM) monitoring.
2. The active pseudo controller sends mobility signaling to all 2. The active pseudo controller sends mobility signaling to all
affected nodes, in this case node B (it has to update the network affected nodes, in this case node B (it has to update the network
service path due to the F3 location update) and node C (as it service path due to the F3 location update) and node C (as it
starts being part of the SFC, hosting F3). The signaling starts being part of the SFC, hosting F3). The signaling
messages are new mobility messages: Service Path Update (SPU) and messages are new mobility messages: Service Path Update (SPU) and
skipping to change at page 8, line 45 skipping to change at page 8, line 4
Lifetime Lifetime
16-bit unsigned integer. The number of time units remaining 16-bit unsigned integer. The number of time units remaining
before the service path MUST be considered expired. A value of before the service path MUST be considered expired. A value of
zero indicates that the Service Path MUST be deleted. A value of zero indicates that the Service Path MUST be deleted. A value of
0xFFFF indicates an infinite lifetime for the Service Path. One 0xFFFF indicates an infinite lifetime for the Service Path. One
time unit is 4 seconds. time unit is 4 seconds.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand. MUST ignore and skip any options that it does not understand.
The following options are valid in a Service Path Update: The following options are valid in a Service Path Update:
Network Service ID. - Network Service ID.
SFC node. - SFC node.
4.2. Service Path Acknowledgement 4.2. Service Path Acknowledgement
The Service Path Acknowledgement (SPA) message is used by a CTRL to The Service Path Acknowledgement (SPA) message is used by a CTRL to
acknowledge a received SPU. acknowledge a received SPU.
The Service Path Acknowledge uses the MH Type value TBD. When this The Service Path Acknowledge uses the MH Type value TBD. When this
value is indicated in the MH Type field, the format of the Message value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows: Data field in the Mobility Header is as follows:
skipping to change at page 9, line 43 skipping to change at page 9, line 4
A 16-bit unsigned integer used to match the returned Service Path A 16-bit unsigned integer used to match the returned Service Path
Acknowledgement with the Service Path Update. Acknowledgement with the Service Path Update.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
Lifetime Lifetime
16-bit unsigned integer. The number of time units remaining 16-bit unsigned integer. The number of time units remaining
before the service path MUST be considered expired. A value of before the service path MUST be considered expired. A value of
zero indicates that the Service Path MUST be deleted. A value of zero indicates that the Service Path MUST be deleted. A value of
0xFFFF indicates an infinite lifetime for the Service Path. One 0xFFFF indicates an infinite lifetime for the Service Path. One
time unit is 4 seconds. time unit is 4 seconds.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand. MUST ignore and skip any options that it does not understand.
The following options are valid in a Service Path Acknowledgement: The following options are valid in a Service Path Acknowledgement:
Network Service ID. - Network Service ID.
4.3. New Mobility options 4.3. New Mobility options
4.3.1. Network Service ID 4.3.1. Network Service ID
The Network Service ID option has the following format: The Network Service ID option has the following format:
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 12, line 39 skipping to change at page 11, line 46
The work in this draft has been partially supported by the H2020 The work in this draft has been partially supported by the H2020
5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881).
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.bernardos-sfc-distributed-control] [I-D.bernardos-sfc-distributed-control]
Bernardos, C. J. and A. Mourad, "Distributed SFC control Bernardos, C. J. and A. Mourad, "Distributed SFC control
for fog environments", draft-bernardos-sfc-distributed- for fog environments", Work in Progress, Internet-Draft,
control-04 (work in progress), July 2021. draft-bernardos-sfc-distributed-control-05, 27 January
2022, <https://www.ietf.org/archive/id/draft-bernardos-
sfc-distributed-control-05.txt>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[I-D.bernardos-sfc-fog-ran] [I-D.bernardos-sfc-fog-ran]
Bernardos, C. J., Rahman, A., and A. Mourad, "Service Bernardos, C. J. and A. Mourad, "Service Function Chaining
Function Chaining Use Cases in Fog RAN", draft-bernardos- Use Cases in Fog RAN", Work in Progress, Internet-Draft,
sfc-fog-ran-09 (work in progress), March 2021. draft-bernardos-sfc-fog-ran-10, 22 October 2021,
<https://www.ietf.org/archive/id/draft-bernardos-sfc-fog-
ran-10.txt>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses Authors' Addresses
Carlos J. Bernardos Carlos J. Bernardos
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
Leganes, Madrid 28911 28911 Leganes, Madrid
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/ URI: http://www.it.uc3m.es/cjbc/
Alain Mourad Alain Mourad
InterDigital Europe InterDigital Europe
Email: Alain.Mourad@InterDigital.com Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/ URI: http://www.InterDigital.com/
 End of changes. 32 change blocks. 
55 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/