< draft-trossen-sfc-name-based-sff-02.txt | draft-trossen-sfc-name-based-sff-03.txt > | |||
---|---|---|---|---|
Network Working Group D. Trossen | Network Working Group D. Trossen | |||
Internet-Draft D. Purkayastha | Internet-Draft InterDigital Europe, Ltd | |||
Intended status: Informational A. Rahman | Intended status: Informational D. Purkayastha | |||
Expires: June 14, 2019 InterDigital Communications, LLC | Expires: August 4, 2019 A. Rahman | |||
December 11, 2018 | InterDigital Communications, LLC | |||
January 31, 2019 | ||||
Name-Based Service Function Forwarder (nSFF) component within SFC | Name-Based Service Function Forwarder (nSFF) component within SFC | |||
framework | framework | |||
draft-trossen-sfc-name-based-sff-02 | draft-trossen-sfc-name-based-sff-03 | |||
Abstract | Abstract | |||
Many stringent requirements are imposed on today's network, such as | Many stringent requirements are imposed on today's network, such as | |||
low latency, high availability and reliability in order to support | low latency, high availability and reliability in order to support | |||
several use cases such as IoT, Gaming, Content distribution, Robotics | several use cases such as IoT, Gaming, Content distribution, Robotics | |||
etc. Adoption of cloud and fog technology at the edge of the network | etc. Adoption of cloud and fog technology at the edge of the network | |||
allows operator to deploy a single "Service Function" to multiple | allows operator to deploy a single "Service Function" to multiple | |||
"Execution locations". The decision to steer traffic to a specific | "Execution locations". The decision to steer traffic to a specific | |||
location may change frequently based on load, proximity etc. Under | location may change frequently based on load, proximity etc. Under | |||
the current SFC framework, steering traffic dynamically to the | the current SFC framework, steering traffic dynamically to the | |||
different execution end points require a specific 're-chaining', | different execution end points require a specific 're-chaining', | |||
i.e., a change in the service function path reflecting the different | i.e., a change in the service function path reflecting the different | |||
IP endpoints to be used for the new execution points. In order to | IP endpoints to be used for the new execution points. This procedure | |||
address this, we discuss separating the logical Service Function Path | maybe complex and take time. In order to simplify re-chaining and | |||
from the specific execution end points. This can be done by | reduce the time to complete the procedure, we discuss separating the | |||
identifying the Service Functions using a name rather than a routable | logical Service Function Path from the specific execution end points. | |||
IP endpoint (or Layer 2 address). This draft describes the necessary | This can be done by identifying the Service Functions using a name | |||
extensions, additional functions and protocol details in SFF (Service | rather than a routable IP endpoint (or Layer 2 address). This draft | |||
Function Forwarder) to handle name based relationships. | describes the necessary extensions, additional functions and protocol | |||
details in SFF (Service Function Forwarder) to handle name based | ||||
relationships. | ||||
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 | |||
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 August 4, 2019. | ||||
This Internet-Draft will expire on June 14, 2019. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 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/license-info) in effect on the date of | (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Example use case: 5G control plane services . . . . . . . . . 4 | 2. Example use case: 5G control plane services . . . . . . . . . 4 | |||
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. Relevant part of SFC architecture . . . . . . . . . . . . 6 | 3.1. Relevant part of SFC architecture . . . . . . . . . . . . 6 | |||
3.2. Challenges with current framework . . . . . . . . . . . . 6 | 3.2. Challenges with current framework . . . . . . . . . . . . 7 | |||
4. Name based operation in SFF . . . . . . . . . . . . . . . . . 7 | 4. Name based operation in SFF . . . . . . . . . . . . . . . . . 8 | |||
4.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 7 | 4.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8 | 4.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8 | |||
4.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 9 | 4.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 10 | |||
4.4. Name-based Service Function Forwarder (nSFF) . . . . . . 11 | 4.4. Name-based Service Function Forwarder (nSFF) . . . . . . 11 | |||
4.5. High Level Architecture . . . . . . . . . . . . . . . . . 12 | 4.5. High Level Architecture . . . . . . . . . . . . . . . . . 12 | |||
4.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 13 | 4.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 13 | |||
5. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 15 | 5. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 15 | |||
5.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 15 | 5.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 15 | |||
5.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 17 | 5.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 17 | 5.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 17 | |||
5.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 18 | 5.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 18 | |||
5.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 19 | 5.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 19 | |||
5.2.4. Remote SF Forwarding . . . . . . . . . . . . . . . . 20 | 5.2.4. Handling of HTTP responses . . . . . . . . . . . . . 20 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 5.2.5. Remote SF Forwarding . . . . . . . . . . . . . . . . 20 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 23 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 | 8. Informative References . . . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
The requirements on today's networks are very diverse, enabling | The requirements on today's networks are very diverse, enabling | |||
multiple use cases such as IoT, Content Distribution, Gaming and | multiple use cases such as IoT, Content Distribution, Gaming and | |||
Network functions such as Cloud RAN and 5G control planes based on a | Network functions such as Cloud RAN and 5G control planes based on a | |||
service-based architecture . These network services are deployed, | service-based architecture . These network services are deployed, | |||
provisioned and managed using Cloud based techniques as seen in the | provisioned and managed using Cloud based techniques as seen in the | |||
IT world. Virtualization of compute and storage resources is at the | IT world. Virtualization of compute and storage resources is at the | |||
heart of providing (often web) services to end users with the ability | heart of providing (often web) services to end users with the ability | |||
skipping to change at page 12, line 32 ¶ | skipping to change at page 12, line 32 ¶ | |||
| Boundary | | | Boundary | | |||
| node | | | node | | |||
+----------+ | +----------+ | |||
Figure 5: High-level architecture | Figure 5: High-level architecture | |||
The high-level architecture for name based operation shown in | The high-level architecture for name based operation shown in | |||
Figure 5 is very similar to the SFC architecture, as described in | Figure 5 is very similar to the SFC architecture, as described in | |||
[RFC7665]. Two new functions are introduced, as shown in the above | [RFC7665]. Two new functions are introduced, as shown in the above | |||
diagram, namely the name-based Service Function Forwarder (nSFF) and | diagram, namely the name-based Service Function Forwarder (nSFF) and | |||
the Name Resolver (NR). The former is an extension of the existing | the Name Resolver (NR). | |||
SFF and is capable of processing SFC packets based on name-based | ||||
network locator map (nNLM) information, determining the next SF, | nSFF (name-based Service Function Forwarder) is an extension of the | |||
where the packet should be forwarded and the required transport | existing SFF and is capable of processing SFC packets based on name- | |||
based network locator map (nNLM) information, determining the next | ||||
SF, where the packet should be forwarded and the required transport | ||||
encapsulation. Like standard SFF operation, it adds transport | encapsulation. Like standard SFF operation, it adds transport | |||
encapsulation to the SFC packet and forwards it. The Name Resolver | encapsulation to the SFC packet and forwards it. | |||
is a new functional component, capable of identifying the execution | ||||
end points, where a "named SF" is running, triggered by suitable | The Name Resolver is a new functional component, capable of | |||
resolution requests sent by the nSFF. | identifying the execution end points, where a "named SF" is running, | |||
triggered by suitable resolution requests sent by the nSFF. Though | ||||
this is similar to DNS function, but it is not same. It does not use | ||||
DNS protocols or data records. A new procedure to determine the | ||||
suitable routing/forwarding information towards the Nsff (Named SFF) | ||||
serving the next hop of the SFP (Serving Function Path) is used. The | ||||
details is described later. | ||||
The other functional components such as Classifier, SF are same as | The other functional components such as Classifier, SF are same as | |||
described in SFC architecture [RFC7665], while the Forwarders shown | described in SFC architecture [RFC7665], while the Forwarders shown | |||
in the above diagram are traditional Layer 2 switches. | in the above diagram are traditional Layer 2 switches. | |||
4.6. Operational Steps | 4.6. Operational Steps | |||
In the proposed solution, the operations are realized by the name- | In the proposed solution, the operations are realized by the name- | |||
based SFF, called nSFF. We utilize the high-level architecture in | based SFF, called nSFF. We utilize the high-level architecture in | |||
Figure 5 to describe the traversal between two service function | Figure 5 to describe the traversal between two service function | |||
skipping to change at page 20, line 10 ¶ | skipping to change at page 20, line 10 ¶ | |||
There are two cases of local SF forwarding, namely the SF sending an | There are two cases of local SF forwarding, namely the SF sending an | |||
SFC packet to the local nSFF (incoming requests) or the nSFF sending | SFC packet to the local nSFF (incoming requests) or the nSFF sending | |||
a packet to the SF (outgoing requests) as part of steps 3 and 10 in | a packet to the SF (outgoing requests) as part of steps 3 and 10 in | |||
Section 4.6. In the following, we outline the operation for HTTP as | Section 4.6. In the following, we outline the operation for HTTP as | |||
an example named transaction. | an example named transaction. | |||
As shown in Figure 8, incoming HTTP requests from SFs are extracted | As shown in Figure 8, incoming HTTP requests from SFs are extracted | |||
by terminating the incoming TCP connection at their local nSFFs at | by terminating the incoming TCP connection at their local nSFFs at | |||
the TCP level. The nSFF MUST maintain a mapping of open TCP sockets | the TCP level. The nSFF MUST maintain a mapping of open TCP sockets | |||
to HTTP requests for HTTP response association. | to HTTP requests (utilizing the URI of the request) for HTTP response | |||
association. | ||||
For outgoing HTTP requests, the nSFF utilizes the maintained mapping | For outgoing HTTP requests, the nSFF utilizes the maintained mapping | |||
of locally registered FQDNs to link-local IP addresses (see | of locally registered FQDNs to link-local IP addresses (see | |||
Section 5.2.2 option 1). Hence, upon receiving an SFC packet from a | Section 5.2.2 option 1). Hence, upon receiving an SFC packet from a | |||
remote nSFF (in step 9 of Section 4.6), the nSFF determines the local | remote nSFF (in step 9 of Section 4.6), the nSFF determines the local | |||
existence of the SF through the registration mechanisms in | existence of the SF through the registration mechanisms in | |||
Section 5.2.2. If said SF does exist locally, the HTTP (+NSH) | Section 5.2.2. If said SF does exist locally, the HTTP (+NSH) | |||
packet, after stripping the TE, is sent to the local SF as step 10 in | packet, after stripping the TE, is sent to the local SF as step 10 in | |||
Section 4.6 via a TCP-level connection. Outgoing nSFF SHOULD keep | Section 4.6 via a TCP-level connection. Outgoing nSFF SHOULD keep | |||
TCP connections open to local SFs for improving SFC packet delivery | TCP connections open to local SFs for improving SFC packet delivery | |||
in subsequent transactions. | in subsequent transactions. | |||
5.2.4. Remote SF Forwarding | 5.2.4. Handling of HTTP responses | |||
When executing step 3 and 10 in Section 4.6, the SFC packet will be | ||||
delivered to the locally registered next hop. As part of the HTTP | ||||
protocol, responses to the HTTP request will need to be delivered on | ||||
the return path to the originating nSFF (i.e. the previous hop). For | ||||
this, the nSFF maintains a list of link-local connection information, | ||||
e.g., sockets to the local SF and the pathID on which the request was | ||||
received. Once receiving the response, nSFF consults the table to | ||||
determine the pathID of the original request, forming a suitable GFF- | ||||
based packet to be returned to the previous nSFF. | ||||
When receiving the HTTP response at the previous nSFF, the nSFF | ||||
consults the table of (locally) open sockets to determine the | ||||
suitable local SF connection, mapping the received HTTP response URI | ||||
to the stored request URI. Utilizing the found socket, the HTTP | ||||
response is forwarded to the locally registered SF. | ||||
To be added later: Handling of semi-synchronous responses from | ||||
different chains to the same SF (with multicast capability) | ||||
[I-D.purkayastha-bier-multicast-http]. | ||||
5.2.5. Remote SF Forwarding | ||||
In steps 5, 6, 7, and 8 of Section 4.6, an SFC packet is forwarded to | In steps 5, 6, 7, and 8 of Section 4.6, an SFC packet is forwarded to | |||
a remote nSFF based on the nNLM information for the next hop of the | a remote nSFF based on the nNLM information for the next hop of the | |||
nSFP. Section 5.2.4.1 handles the case of suitable forwarding | nSFP. Section 5.2.4.1 handles the case of suitable forwarding | |||
information to the remote nSFF not existing, therefore consulting the | information to the remote nSFF not existing, therefore consulting the | |||
NR to obtain suitable information, while Section 5.2.4.2 describes | NR to obtain suitable information, while Section 5.2.4.2 describes | |||
the maintenance of forwarding information at the local nSFF, while | the maintenance of forwarding information at the local nSFF, while | |||
Section 5.2.4.3 describes the update of stale forwarding information. | Section 5.2.4.3 describes the update of stale forwarding information. | |||
Note that the forwarding described in Section 5.2.1 is used for the | Note that the forwarding described in Section 5.2.1 is used for the | |||
actual forwarding to the various nSFF components. Ultimately, | actual forwarding to the various nSFF components. Ultimately, | |||
Section 5.2.4.4 describes the forwarding to the remote nSFF via the | Section 5.2.4.4 describes the forwarding to the remote nSFF via the | |||
forwarder network | forwarder network | |||
5.2.4.1. Remote SF Discovery | 5.2.5.1. Remote SF Discovery | |||
The nSFF communicates with the NR for two purposes, namely the | The nSFF communicates with the NR for two purposes, namely the | |||
registration and discovery of FQDNs. The packet format for the | registration and discovery of FQDNs. The packet format for the | |||
former was shown in Figure 10 in Section 5.2.2, while Figure 11 | former was shown in Figure 10 in Section 5.2.2, while Figure 11 | |||
outlines the packet format for the discovery request. A path to a | outlines the packet format for the discovery request. A path to a | |||
specific FQDN is requested by sending a hash of the FQDN to the NR | specific FQDN is requested by sending a hash of the FQDN to the NR | |||
together with its nSFF_id, receiving as a response a pathID with a | together with its nSFF_id, receiving as a response a pathID with a | |||
length identifier. The NR should maintain a table of discovery | length identifier. The NR should maintain a table of discovery | |||
requests that map discovered (hash of) FQDN to the nSFF_id that | requests that map discovered (hash of) FQDN to the nSFF_id that | |||
requested it and the pathID that is being calculated as a result of | requested it and the pathID that is being calculated as a result of | |||
skipping to change at page 21, line 21 ¶ | skipping to change at page 21, line 44 ¶ | |||
+--------------+-------------+ +--------+-----------------//--------+ | +--------------+-------------+ +--------+-----------------//--------+ | |||
| | | | | // | | | | | | | // | | |||
| hash(FQDN) | nSFF_ID | | Length | pathID // | | | hash(FQDN) | nSFF_ID | | Length | pathID // | | |||
| (16 bit) | (8 bit) | | (4 bit)| // | | | (16 bit) | (8 bit) | | (4 bit)| // | | |||
+--------------+-------------+ +--------+-------------//------------+ | +--------------+-------------+ +--------+-------------//------------+ | |||
Path Request Path Response | Path Request Path Response | |||
Figure 11: Discovery packet format | Figure 11: Discovery packet format | |||
5.2.4.2. Maintaining Forwarding Information at Local nSFF | 5.2.5.2. Maintaining Forwarding Information at Local nSFF | |||
Each nSFF MUST maintain an internal table that maps the (hash of the) | Each nSFF MUST maintain an internal table that maps the (hash of the) | |||
FQDN information to a suitable pathID information. As outlined in | FQDN information to a suitable pathID information. As outlined in | |||
step 7 of Section 4.6, if a suitable entry does not exist for a given | step 7 of Section 4.6, if a suitable entry does not exist for a given | |||
FQDN, the pathID information is requested with the operations in | FQDN, the pathID information is requested with the operations in | |||
Section 5.2.4.1 and the suitable entry is locally created upon | Section 5.2.4.1 and the suitable entry is locally created upon | |||
receiving a reply with the forwarding operation being executed as | receiving a reply with the forwarding operation being executed as | |||
described in Section 5.2.1. | described in Section 5.2.1. | |||
If such entry does exist (i.e., step 6 of Section 4.6) the pathID is | If such entry does exist (i.e., step 6 of Section 4.6) the pathID is | |||
locally retrieved and used for the forwarding operation in | locally retrieved and used for the forwarding operation in | |||
Section 5.2.1. | Section 5.2.1. | |||
5.2.4.3. Updating Forwarding Information at nSFF | 5.2.5.3. Updating Forwarding Information at nSFF | |||
The forwarding information maintained at each nSFF (see | The forwarding information maintained at each nSFF (see | |||
Section 5.2.4.2) might need to be updated for three reasons: | Section 5.2.4.2) might need to be updated for three reasons: | |||
o An existing SF is no longer reachable: In this case, the nSFF with | o An existing SF is no longer reachable: In this case, the nSFF with | |||
which the SF is locally registered, deregisters the SF explicitly | which the SF is locally registered, deregisters the SF explicitly | |||
at the NR by sending the packet in Figure 10 with the hashed FQDN | at the NR by sending the packet in Figure 10 with the hashed FQDN | |||
and the R/D bit set to 1 (for deregister). | and the R/D bit set to 1 (for deregister). | |||
o Another SF instance has become reachable in the network (and | o Another SF instance has become reachable in the network (and | |||
skipping to change at page 22, line 26 ¶ | skipping to change at page 22, line 48 ¶ | |||
Section 5.2.2. | Section 5.2.2. | |||
+---------+-----------------+--------------//----+ | +---------+-----------------+--------------//----+ | |||
| | | // | | | | | // | | |||
| Type | #IDs | IDs // | | | Type | #IDs | IDs // | | |||
| (1 bit) | (8 bit) | // | | | (1 bit) | (8 bit) | // | | |||
+---------+-----------------+----------//--------+ | +---------+-----------------+----------//--------+ | |||
Figure 12: Path update format | Figure 12: Path update format | |||
The pathID may include the type of information being updated (e.g., | ||||
node identifiers of leaf nodes or link identifiers for removed | ||||
links). The node identifier itself may be a special identifier to | ||||
signal "ALL NODES" as being affected. The node identifier may signal | ||||
changes to the network that are substantial (e.g., parallel link | ||||
failures). The node identifier may trigger (e.g., recommend) purging | ||||
of the entire path table (e.g., rather than the selective removal of | ||||
a few nodes only). | ||||
It will include the information according to the type. The included | ||||
information may also be related to the type and length information | ||||
for the number of identifiers being provided. | ||||
In case 1 and 2, the Type bit is set to 1 (type nSFF_id) and the | In case 1 and 2, the Type bit is set to 1 (type nSFF_id) and the | |||
affected nSFFs are determined by those nSFFs that have previously | affected nSFFs are determined by those nSFFs that have previously | |||
sent SF discovery requests, utilizing the optional table mapping | sent SF discovery requests, utilizing the optional table mapping | |||
previously registered FQDNs to nSFF_id values. If no table mapping | previously registered FQDNs to nSFF_id values. If no table mapping | |||
the (hash of) FQDN to nSFF_id is maintained, the update is sent to | the (hash of) FQDN to nSFF_id is maintained, the update is sent to | |||
all nSFFs. Upon receiving the path update at the affected nSFF, all | all nSFFs. Upon receiving the path update at the affected nSFF, all | |||
appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) | appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) | |||
identifiers provided will be removed, leading to a new NR discovery | identifiers provided will be removed, leading to a new NR discovery | |||
request at the next remote nSFF forwarding to the appropriate FQDN. | request at the next remote nSFF forwarding to the appropriate FQDN. | |||
In case 3, the Type bit is set to 0 (type linkID) and the affected | In case 3, the Type bit is set to 0 (type linkID) and the affected | |||
nSFFs are determined by those nSFFs whose discovery requests have | nSFFs are determined by those nSFFs whose discovery requests have | |||
previously resulted in pathIDs which include the affected link, | previously resulted in pathIDs which include the affected link, | |||
utilizing the optional table mapping previously registered FQDNs to | utilizing the optional table mapping previously registered FQDNs to | |||
pathID values (see Section 5.2.4.1). Upon receiving the path update, | pathID values (see Section 5.2.4.1). Upon receiving the node | |||
the affected nSFF will check its internal table that maps FQDNs to | identifier information in the path update, the affected nSFF will | |||
pathIDs to determine those pathIDs affected by the link problems. | check its internal table that maps FQDNs to pathIDs to determine | |||
For this, the pathID entries of said table are checked against the | those pathIDs affected by the link problems and remove path | |||
linkID values provided in the ID entry of the path update through a | information that includes the received node identifier(s). For this, | |||
binary AND/CMP operation to check the inclusion of the link in the | the pathID entries of said table are checked against the linkID | |||
pathIDs to the FQDNs. If any pathID is affected, the FQDN-pathID | values provided in the ID entry of the path update through a binary | |||
entry is removed, leading to a new NR discovery request at the next | AND/CMP operation to check the inclusion of the link in the pathIDs | |||
remote nSFF forwarding to the appropriate FQDN. | to the FQDNs. If any pathID is affected, the FQDN-pathID entry is | |||
removed, leading to a new NR discovery request at the next remote | ||||
nSFF forwarding to the appropriate FQDN. | ||||
5.2.4.4. Forwarding to remote nSFF | 5.2.5.4. Forwarding to remote nSFF | |||
Once step 5, 6, and 7 in Section 4.6 are being executed, step 8 | Once step 5, 6, and 7 in Section 4.6 are being executed, step 8 | |||
finally sends the SFC packet to the remote nSFF, utilizing the pathID | finally sends the SFC packet to the remote nSFF, utilizing the pathID | |||
returned in the discovery request (Section 5.2.4.1) or retrieved from | returned in the discovery request (Section 5.2.4.1) or retrieved from | |||
the local pathID mapping table. The SFC packet is placed in the | the local pathID mapping table. The SFC packet is placed in the | |||
payload of the generic forwarding format in Figure 14 together with | payload of the generic forwarding format in Figure 14 together with | |||
the pathID and the nSFF eventually executes the forwarding operations | the pathID and the nSFF eventually executes the forwarding operations | |||
in Section 5.2.1. | in Section 5.2.1. | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document requests no IANA actions. | This document requests no IANA actions. | |||
7. Security Considerations | 7. Security Considerations | |||
The operations in Section 4 and 5 consider the forwarding of SFC | The operations in Section 4 and 5 describes the forwarding of SFC | |||
packets between named SFs based on HTTP. The support for HTTPS is | packets between named SFs based on URIs exchanged in HTTP messages. | |||
foreseen to ensure suitable encryption capability of such exchanges. | For security considerations, TLS is sufficient between originating | |||
Future updates to this draft will outline the support for such HTTPS- | node and Nsff, Nsff to Nsff, Nsff to destination. TLS handshake | |||
based SFC exchanges. | allows to determine the FQDN, which in turn is enough for the service | |||
routing decision. Supporting TLS also allows the possibility of | ||||
HTTPS based transactions. | ||||
8. Informative References | 8. Informative References | |||
[_3GPP_SBA] | [_3GPP_SBA] | |||
3GPP, "Technical Realization of Service Based | 3GPP, "Technical Realization of Service Based | |||
Architecture", 3GPP TS 29.500 0.4.0, January 2018, | Architecture", 3GPP TS 29.500 0.4.0, January 2018, | |||
<http://www.3gpp.org/ftp/Specs/html-info/29500.htm>. | <http://www.3gpp.org/ftp/Specs/html-info/29500.htm>. | |||
[_3GPP_SBA_ENHANCEMENT] | [_3GPP_SBA_ENHANCEMENT] | |||
3GPP, "New SID for Enhancements to the Service-Based 5G | 3GPP, "New SID for Enhancements to the Service-Based 5G | |||
skipping to change at page 24, line 26 ¶ | skipping to change at page 25, line 16 ¶ | |||
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index | Przygienda, T., and S. Aldrin, "Multicast Using Bit Index | |||
Explicit Replication (BIER)", RFC 8279, | Explicit Replication (BIER)", RFC 8279, | |||
DOI 10.17487/RFC8279, November 2017, | DOI 10.17487/RFC8279, November 2017, | |||
<https://www.rfc-editor.org/info/rfc8279>. | <https://www.rfc-editor.org/info/rfc8279>. | |||
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | |||
"Network Service Header (NSH)", RFC 8300, | "Network Service Header (NSH)", RFC 8300, | |||
DOI 10.17487/RFC8300, January 2018, | DOI 10.17487/RFC8300, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8300>. | <https://www.rfc-editor.org/info/rfc8300>. | |||
Appendix A. Change Log | ||||
[Note to Editor: Please remove this section before publication.] | ||||
Changes from 01 version: | ||||
o Added this Change Log in Appendix A. | ||||
o Addressed Editorial Comments (nits) throughout the document from | ||||
Dirk Hugo, DT. | ||||
o Section 4.1, added a paragraph to clarify the execution path of | ||||
nSFF when the next hop is identified by L2/L3 identifier or by | ||||
using Name. | ||||
o Section 5.1, added paragraphs to clarify how TCP connection is | ||||
terminated and handled at the ingress nSFF and egress nSFF. | ||||
Authors' Addresses | Authors' Addresses | |||
Dirk Trossen | Dirk Trossen | |||
InterDigital Communications, LLC | InterDigital Europe, Ltd | |||
64 Great Eastern Street, 1st Floor | 64 Great Eastern Street, 1st Floor | |||
London EC2A 3QR | London EC2A 3QR | |||
United Kingdom | United Kingdom | |||
Email: Dirk.Trossen@InterDigital.com | Email: Dirk.Trossen@InterDigital.com | |||
URI: http://www.InterDigital.com/ | ||||
Debashish Purkayastha | Debashish Purkayastha | |||
InterDigital Communications, LLC | InterDigital Communications, LLC | |||
1001 E Hector St | ||||
Conshohocken | Conshohocken | |||
USA | USA | |||
Email: Debashish.Purkayastha@InterDigital.com | Email: Debashish.Purkayastha@InterDigital.com | |||
Akbar Rahman | Akbar Rahman | |||
InterDigital Communications, LLC | InterDigital Communications, LLC | |||
1000 Sherbrooke Street West | ||||
Montreal | Montreal | |||
Canada | Canada | |||
Email: Akbar.Rahman@InterDigital.com | Email: Akbar.Rahman@InterDigital.com | |||
End of changes. 26 change blocks. | ||||
74 lines changed or deleted | 108 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |