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