| < 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/ | ||||