[要約] RFC 8677は、SFCフレームワーク内のnSFFコンポーネントに関する仕様であり、名前ベースのサービス機能フォワーダーの役割を定義しています。このRFCの目的は、SFC内でのサービスチェーンの柔軟性と拡張性を向上させることです。
Independent Submission D. Trossen
Request for Comments: 8677 InterDigital Europe, Ltd
Category: Informational D. Purkayastha
ISSN: 2070-1721 A. Rahman
InterDigital Communications, LLC
November 2019
Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework
Service Function Chaining（SFC）フレームワーク内の名前ベースのService Function Forwarder（nSFF）コンポーネント
Abstract
概要
Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.
クラウドおよびフォグ技術の採用により、オペレーターは単一の「サービス機能」（SF）を複数の「実行場所」に展開できます。トラフィックを特定の場所に誘導する決定は、負荷、近接性などに基づいて頻繁に変わる可能性があります。現在のService Function Chaining（SFC）フレームワークでは、異なる実行エンドポイントに動的にトラフィックを誘導するには、特定の「再チェーン」、つまり変更が必要です新しい実行ポイントに使用されるさまざまなIPエンドポイントを反映するサービス関数パス。この手順は複雑で時間がかかる場合があります。再チェーンを簡略化し、手順を完了する時間を短縮するために、特定の実行エンドポイントから論理サービス関数パス（SFP）を分離することについて説明します。これは、ルーティング可能なIPエンドポイント（またはレイヤー2アドレス）ではなく名前を使用してSFを識別することで実行できます。このドキュメントでは、名前ベースの関係を処理するために必要な拡張機能、追加機能、およびService Function Forwarder（SFF）のプロトコルの詳細について説明します。
This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.
このドキュメントでは、名前ベースのSFCに対するInterDigitalのアプローチを紹介します。これはIETFの合意を表すものではなく、SFCコミュニティがこのメカニズムとエッジデータセンターでの使用の可能性を検討することでメリットを得られるように、ここに提示されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8677.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8677で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Example Use Case: 5G Control-Plane Services
4. Background
4.1. Relevant Part of SFC Architecture
4.2. Challenges with Current Framework
5. Name-Based Operation in SFF
5.1. General Idea
5.2. Name-Based Service Function Path (nSFP)
5.3. Name-Based Network Locator Map (nNLM)
5.4. Name-Based Service Function Forwarder (nSFF)
5.5. High-Level Architecture
5.6. Operational Steps
6. nSFF Forwarding Operations
6.1. nSFF Protocol Layers
6.2. nSFF Operations
6.2.1. Forwarding between nSFFs and nSFF-NRs
6.2.2. SF Registration
6.2.3. Local SF Forwarding
6.2.4. Handling of HTTP Responses
6.2.5. Remote SF Forwarding
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The requirements on today's networks are very diverse, enabling multiple use cases such as the Internet of Things (IoT), Content Distribution, Gaming, and Network functions such as Cloud Radio Access Network (RAN) and 5G control planes based on a Service-Based Architecture (SBA). These services are deployed, provisioned, and managed using Cloud-based techniques as seen in the IT world. Virtualization of compute and storage resources is at the heart of providing (often web) services to end users with the ability to quickly provision virtualized service endpoints through, e.g., container-based techniques. This creates the ability to dynamically compose new services from existing services. It also allows an operator to move a service instance in response to user mobility or to change resource availability. When moving from a purely "distant cloud" model to one of localized micro data centers with regional, metro, or even street level, often called "edge" data centers, such virtualized service instances can be instantiated in topologically different locations with the overall "distant" data center now being transformed into a network of distributed ones. The reaction of content providers, like Facebook, Google, NetFlix, and others, is not just to rely on deploying content servers at the ingress of the customer network. Instead, the trend is towards deploying multiple Point of Presences (POPs) within the customer network, those POPs being connected through proprietary mechanisms [Schlinker2017] to push content.
今日のネットワークの要件は非常に多様であり、モノのインターネット（IoT）、コンテンツ配信、ゲーム、およびクラウド無線アクセスネットワーク（RAN）やサービスベースの5Gコントロールプレーンなどのネットワーク機能など、複数の使用例が可能ですアーキテクチャ（SBA）。これらのサービスは、ITの世界で見られるように、クラウドベースの技術を使用して展開、プロビジョニング、および管理されます。コンピューティングリソースとストレージリソースの仮想化は、エンドユーザーにサービス（多くの場合はWeb）を提供する中心的な役割を担っており、コンテナーベースの手法などを通じて仮想化されたサービスエンドポイントをすばやくプロビジョニングできます。これにより、既存のサービスから新しいサービスを動的に構成する機能が作成されます。また、オペレーターは、ユーザーの移動に応じてサービスインスタンスを移動したり、リソースの可用性を変更したりできます。純粋な「遠いクラウド」モデルから、地域、メトロ、またはストリートレベルのローカライズされたマイクロデータセンター（「エッジ」データセンターと呼ばれることも多い）の1つに移動すると、そのような仮想化サービスインスタンスは、遠く離れた」データセンターは現在、分散型のデータセンターのネットワークに変換されています。 Facebook、Google、NetFlixなどのコンテンツプロバイダーの反応は、顧客ネットワークの入口にコンテンツサーバーを展開することに依存するだけではありません。代わりに、顧客ネットワーク内に複数のPOP（Point of Presence）を展開する傾向があり、これらのPOPは独自のメカニズム[Schlinker2017]を介して接続され、コンテンツをプッシュします。
The Service Function Chaining (SFC) framework [RFC7665] allows network operators as well as service providers to compose new services by chaining individual "service functions". Such chains are expressed through explicit relationships of functional components (the SFs) realized through their direct Layer 2 (e.g., Media Access Control (MAC) address) or Layer 3 (e.g., IP address) relationship as defined through next-hop information that is being defined by the network operator. See Section 4 for more background on SFC.
Service Function Chaining（SFC）フレームワーク[RFC7665]を使用すると、ネットワークオペレーターだけでなくサービスプロバイダーも、個々の「サービス機能」をチェーン化して新しいサービスを構成できます。このようなチェーンは、ネクストホップ情報で定義されている直接のレイヤー2（メディアアクセスコントロール（MAC）アドレスなど）またはレイヤー3（IPアドレスなど）の関係によって実現される機能コンポーネント（SF）の明示的な関係によって表されます。ネットワークオペレータによって定義されています。 SFCの背景については、セクション4を参照してください。
In a dynamic service environment of distributed data centers such as the one outlined above, with the ability to create and recreate service endpoints frequently, the SFC framework requires reconfiguring the existing chain through information based on the new relationships, causing overhead in a number of components, specifically the orchestrator that initiates the initial SFC and any possible reconfiguration.
上記のような分散データセンターの動的サービス環境では、サービスエンドポイントを頻繁に作成および再作成できるため、SFCフレームワークでは、新しい関係に基づく情報を通じて既存のチェーンを再構成する必要があり、多くのコンポーネントでオーバーヘッドが発生します。具体的には、初期SFCと可能な再構成を開始するオーケストレーター。
This document describes how such changes can be handled without involving the initiation of new and reconfigured SFCs. This is accomplished by lifting the chaining relationship from Layer 2 and Layer 3 information to that of SF "names", which can, for instance, be expressed as URIs. In order to transparently support such named relationships, we propose to embed the necessary functionality directly into the Service Function Forwarder (SFF) as described in [RFC7665]. With that, the SFF described in this document allows for keeping an existing SFC intact, as described by its Service Function Path (SFP), while enabling the selection of appropriate service function endpoint(s) during the traversal of packets through the SFC. This document is an Independent Submission to the RFC Editor. It is not an output of the IETF SFC WG.
このドキュメントでは、新規および再構成されたSFCの開始を伴わずに、そのような変更を処理する方法について説明します。これは、連鎖関係をレイヤー2およびレイヤー3の情報から、たとえばURIとして表現できるSFの「名前」の情報に持ち上げることによって実現されます。このような名前付きの関係を透過的にサポートするために、[RFC7665]で説明されているように、必要な機能をService Function Forwarder（SFF）に直接埋め込むことを提案します。これにより、このドキュメントで説明されているSFFは、サービス機能パス（SFP）で説明されているように既存のSFCをそのまま維持し、SFCを介したパケットのトラバース中に適切なサービス機能エンドポイントを選択できるようにします。このドキュメントはRFCエディタへの独立した提出です。 IETF SFC WGの出力ではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
We exemplify the need for chaining SFs at the level of a service name through a use case stemming from the current 3GPP Release 16 work on Service Based Architecture (SBA) [SDO-3GPP-SBA], [SDO-3GPP-SBA-ENHANCEMENT]. In this work, mobile network control planes are proposed to be realized by replacing the traditional network function interfaces with a fully service-based one. HTTP was chosen as the application-layer protocol for exchanging suitable service requests [SDO-3GPP-SBA]. With this in mind, the exchange between, for example, the 3GPP-defined (Rel. 15) Session Management Function (SMF) and the Access and Mobility Management Function (AMF) in a 5G control plane is being described as a set of web-service-like requests that are, in turn, embedded into HTTP requests. Hence, interactions in a 5G control plane can be modeled based on SFCs where the relationship is between the specific (IP-based) SF endpoints that implement the necessary service endpoints in the SMF and AMF. The SFs are exposed through URIs with work ongoing to define the used naming conventions for such URIs.
サービスベースのアーキテクチャ（SBA）[SDO-3GPP-SBA]、[SDO-3GPP-SBA-ENHANCEMENT]に関する現在の3GPPリリース16の作業に由来するユースケースを通じて、サービス名のレベルでSFをチェーンする必要性を例示します。 。この作業では、モバイルネットワークコントロールプレーンを、従来のネットワーク機能インターフェイスを完全にサービスベースのインターフェイスに置き換えることで実現することが提案されています。適切なサービス要求を交換するためのアプリケーション層プロトコルとしてHTTPが選択されました[SDO-3GPP-SBA]。これを念頭に置いて、たとえば、3GPP定義（Rel。15）セッション管理機能（SMF）と5Gコントロールプレーンのアクセスおよびモビリティ管理機能（AMF）の間の交換は、Webのセットとして説明されています。 -serviceのようなリクエストで、HTTPリクエストに埋め込まれます。したがって、5Gコントロールプレーンの相互作用は、SMFおよびAMFに必要なサービスエンドポイントを実装する特定の（IPベースの）SFエンドポイント間の関係であるSFCに基づいてモデル化できます。 SFはURIを通じて公開され、そのようなURIに使用される命名規則を定義する作業が進行中です。
This move from a network function model (in pre-Release 15 systems of 3GPP) to a service-based model is motivated through the proliferation of data-center operations for mobile network control-plane services. In other words, typical IT-based methods to service provisioning, particularly that of virtualization of entire compute resources, are envisioned to being used in future operations of mobile networks. Hence, operators of such future mobile networks desire to virtualize SF endpoints and direct (control-plane) traffic to the most appropriate current service instance in the most appropriate (local) data center. Such a data center is envisioned as being interconnected through a software-defined wide area network (SD-WAN). "Appropriate" here can be defined by topological or geographical proximity of the service initiator to the SF endpoint. Alternatively, network or service instance compute load can be used to direct a request to a more appropriate (in this case less loaded) instance to reduce possible latency of the overall request. Such data-center-centric operation is extended with the trend towards regionalization of load through a "regional office" approach, where micro data centers provide virtualizable resources that can be used in the service execution, creating a larger degree of freedom when choosing the "most appropriate" service endpoint for a particular incoming service request.
ネットワーク機能モデル（3GPPのリリース15より前のシステム）からサービスベースのモデルへの移行は、モバイルネットワークコントロールプレーンサービスのデータセンター運用の急増を通じて動機付けられました。言い換えれば、サービスプロビジョニングの典型的なITベースの方法、特にコンピューティングリソース全体の仮想化の方法は、モバイルネットワークの将来の運用で使用されることを想定しています。したがって、そのような将来のモバイルネットワークの事業者は、SFエンドポイントを仮想化し、（コントロールプレーン）トラフィックを最も適切な（ローカル）データセンターの最も適切な現在のサービスインスタンスに転送することを望んでいます。このようなデータセンターは、ソフトウェア定義の広域ネットワーク（SD-WAN）を介して相互接続されていると想定されています。ここで「適切」とは、SFエンドポイントに対するサービスイニシエーターのトポロジ的または地理的な近接度によって定義できます。または、ネットワークまたはサービスインスタンスの計算負荷を使用して、要求をより適切な（この場合は負荷が少ない）インスタンスに送信して、要求全体の潜在的な待ち時間を減らすことができます。このようなデータセンター中心の運用は、「地域オフィス」アプローチを通じて負荷を地域化する傾向に拡張され、マイクロデータセンターは、サービスの実行に使用できる仮想化可能なリソースを提供し、「特定の着信サービス要求に最も適した」サービスエンドポイント。
While the move to a service-based model aligns well with the framework of SFC, choosing the most appropriate service instance at runtime requires so-called "rechaining" of the SFC since the relationships in said SFC are defined through Layer 2 or Layer 3 identifiers, which, in turn, are likely to be different if the chosen service instances reside in different parts of the network (e.g., in a regional data center).
サービスベースのモデルへの移行はSFCのフレームワークとうまく調和しますが、実行時に最も適切なサービスインスタンスを選択するには、SFCのいわゆる「再チェーン」が必要です。これは、SFCの関係がレイヤー2またはレイヤー3の識別子を通じて定義されているためです。は、選択されたサービスインスタンスがネットワークの異なる部分（たとえば、地域のデータセンター）にある場合は、異なる可能性があります。
Hence, when a traffic flow is forwarded over a service chain expressed as an SFC-compliant SFP, packets in the traffic flow are processed by the various SF instances, with each SF instance applying an SF prior to forwarding the packets to the next network node. It is a service-layer concept and can possibly work over any Virtual network layer and corresponding underlay network. The underlay network can be IP or alternatively any Layer 2 technology. At the service layer, SFs are identified using a path identifier and an index. Eventually, this index is translated to an IP address (or MAC address) of the host where the SF is running. Because of this, any change-of-service function instance is likely to require a change of the path information since either the IP address (in the case of changing the execution from one data center to another) or MAC address will change due to the newly selected SF instance.
したがって、トラフィックフローがSFC準拠のSFPとして表現されたサービスチェーンを介して転送されると、トラフィックフロー内のパケットはさまざまなSFインスタンスによって処理され、各SFインスタンスはパケットを次のネットワークノードに転送する前にSFを適用します。これはサービス層の概念であり、仮想ネットワーク層および対応するアンダーレイネットワーク上で機能する可能性があります。アンダーレイネットワークは、IPまたはレイヤー2テクノロジです。サービス層では、パス識別子とインデックスを使用してSFが識別されます。最終的に、このインデックスは、SFが実行されているホストのIPアドレス（またはMACアドレス）に変換されます。このため、IPアドレス（あるデータセンターから別のデータセンターに実行を変更する場合）またはMACアドレスのいずれかが原因で変更されるため、サービス変更機能のインスタンスではパス情報の変更が必要になる可能性があります。新しく選択されたSFインスタンス。
Returning to our 5G control-plane example, a user's connection request to access an application server in the Internet may start with signaling in the control plane to set up user-plane bearers. The connection request may flow through SFs over a service chain in the control plane, as deployed by a network operator. Typical SFs in a 5G control plane may include "RAN termination / processing", "Slice Selection Function", "AMF", and "SMF". A "Network Slice" is a complete logical network including Radio Access Network (RAN) and Core Network (CN). Distinct RAN and CN Slices may exist. A device may access multiple Network Slices simultaneously through a single RAN. The device may provide Network Slice Selection Assistance Information (NSSAI) parameters to the network to help it select a RAN and a Core Network part of a slice instance. Part of the control plane, the Common Control Network Function (CCNF), includes the Network Slice Selection Function (NSSF), which is in charge of selecting core Network Slice instances. The classifier, as described in SFC architecture, may reside in the user terminal or at the Evolved Node B (eNB). These SFs can be configured to be part of an SFC. We can also say that some of the configurations of the SFP may change at the execution time. For example, the SMF may be relocated as the user moves and a new SMF may be included in the SFP based on user location. Figure 1 shows the example SFC described here.
5Gコントロールプレーンの例に戻ると、インターネットのアプリケーションサーバーにアクセスするためのユーザーの接続要求は、ユーザープレーンベアラーをセットアップするためのコントロールプレーンでのシグナリングから始まる場合があります。接続要求は、ネットワークオペレータによって展開されるように、コントロールプレーンのサービスチェーンを介してSFを通過します。 5Gコントロールプレーンの一般的なSFには、「RAN終了/処理」、「スライス選択機能」、「AMF」、および「SMF」が含まれます。 「ネットワークスライス」は、無線アクセスネットワーク（RAN）およびコアネットワーク（CN）を含む完全な論理ネットワークです。異なるRANおよびCNスライスが存在する場合があります。デバイスは、単一のRANを通じて複数のネットワークスライスに同時にアクセスできます。デバイスは、ネットワークスライス選択支援情報（NSSAI）パラメータをネットワークに提供して、スライスインスタンスのRANおよびコアネットワーク部分を選択するのに役立つ場合があります。コントロールプレーンの一部であるCommon Control Network Function（CCNF）には、コアネットワークスライスインスタンスの選択を担当するNetwork Slice Selection Function（NSSF）が含まれています。分類子は、SFCアーキテクチャーで説明されているように、ユーザー端末内またはEvolved Node B（eNB）に常駐できます。これらのSFは、SFCの一部として構成できます。また、SFPの構成の一部は、実行時に変更される可能性があるとも言えます。たとえば、ユーザーの移動に応じてSMFを再配置し、ユーザーの場所に基づいて新しいSMFをSFPに含めることができます。図1は、ここで説明するSFCの例を示しています。
+------+ +---------+ +-----+ +-----+
| User | | Slice | | | | |
| App |-->| Control |->| AMF |-->| SMF |-->
| Fn | | Function| | | | |
+------+ +---------+ +-----+ +-----+
Figure 1: Mapping SFC onto Service Function Execution Points along a Service Function Path
図1：サービス機能パスに沿ったサービス機能実行ポイントへのSFCのマッピング
[RFC7665] describes an architecture for the specification, creation, and ongoing maintenance of SFCs. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. In the following, we outline the parts of this SFC architecture relevant for our proposed extension, followed by the challenges with this current framework in the light of our example use case.
[RFC7665]は、SFCの仕様、作成、および継続的なメンテナンスのアーキテクチャについて説明しています。 SFCの展開による複合サービスの構築に使用されるアーキテクチャの概念、原則、およびコンポーネントが含まれています。以下では、提案された拡張に関連するこのSFCアーキテクチャの部分について概説し、その後、使用例に照らしてこの現在のフレームワークでの課題を説明します。
The SFC architecture, as defined in [RFC7665], describes architectural components such as SF, classifier, and SFF. It describes the SFP as the logical path of an SFC. Forwarding traffic along such an SFP is the responsibility of the SFF. For this, the SFFs in a network maintain the requisite SFP forwarding information. Such SFP forwarding information is associated with a service path identifier (SPI) that is used to uniquely identify an SFP. The service forwarding state is represented by the Service Index (SI) and enables an SFF to identify which SFs of a given SFP should be applied, and in what order. The SFF also has information that allows it to forward packets to the next SFF after applying local SFs.
[RFC7665]で定義されているSFCアーキテクチャは、SF、分類子、SFFなどのアーキテクチャコンポーネントを記述しています。 SFPをSFCの論理パスとして記述します。そのようなSFPに沿ってトラフィックを転送することはSFFの責任です。このため、ネットワーク内のSFFは必要なSFP転送情報を維持します。このようなSFP転送情報は、SFPを一意に識別するために使用されるサービスパス識別子（SPI）に関連付けられています。サービス転送状態はサービスインデックス（SI）で表され、SFFが特定のSFPのどのSFをどの順序で適用するかを識別できるようにします。 SFFには、ローカルSFを適用した後にパケットを次のSFFに転送できるようにする情報もあります。
The operational steps to forward traffic are then as follows: Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. After SF processing, the traffic is returned to the SFF and, if needed, is forwarded to another SF associated with that SFF. If there is another non-local hop (i.e., to an SF with a different SFF) in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata.
トラフィックを転送する操作手順は次のとおりです。トラフィックはネットワークからSFFに到着します。 SFFは、SFCカプセル化に含まれる情報を介してトラフィックが転送される適切なSFを決定します。 SF処理後、トラフィックはSFFに戻され、必要に応じて、そのSFFに関連付けられた別のSFに転送されます。 SFPに別の非ローカルホップ（つまり、SFFが異なるSFへ）がある場合、SFFはさらにトラフィックを適切なネットワーク転送プロトコルにカプセル化し、パスに沿って次のSFFに配信するためにネットワークに配信します。この転送責任に関連して、SFFはメタデータと対話できる必要があります。
As outlined in previous sections, the SFP defines an ordered sequence of specific SF instances being used for the interaction between initiator and SFs along the SFP. These SFs are addressed by IP (or any L2/MAC) addresses and defined as next-hop information in the network locator maps of traversing SFF nodes.
前のセクションで概説したように、SFPは、SFPに沿ったイニシエーターとSF間の相互作用に使用される特定のSFインスタンスの順序付けられたシーケンスを定義します。これらのSFは、IP（または任意のL2 / MAC）アドレスによってアドレス指定され、通過するSFFノードのネットワークロケーターマップでネクストホップ情報として定義されます。
As outlined in our use case, however, the service provider may want to provision SFC nodes based on dynamically spun-up SF instances so that these (now virtualized) SFs can be reached in the SFC domain using the SFC underlay layer.
ただし、ユースケースで概説されているように、サービスプロバイダーは、動的にスピンアップされたSFインスタンスに基づいてSFCノードをプロビジョニングして、SFCアンダーレイレイヤーを使用してSFCドメインでこれらの（現在は仮想化された）SFに到達できるようにする場合があります。
Following the original model of SFC, any change in a specific execution point for a specific SF along the SFP will require a change of the SFP information (since the new SF execution point likely carries different IP or L2 address information) and possibly even the next-hop information in SFFs along the SFP. In case the availability of new SF instances is rather dynamic (e.g., through the use of container-based virtualization techniques), the current model and realization of SFC could lead to reducing the flexibility of service providers and increasing the management complexity incurred by the frequent changes of (service) forwarding information in the respective SFF nodes. This is because any change of the SFP (and possibly next-hop info) will need to go through suitable management cycles.
SFCの元のモデルに従って、SFPに沿った特定のSFの特定の実行ポイントを変更すると、SFP情報の変更が必要になります（新しいSF実行ポイントは異なるIPまたはL2アドレス情報を運ぶ可能性が高いため）。 -SFPに沿ったSFF内のホップ情報。新しいSFインスタンスの可用性がかなり動的である場合（たとえば、コンテナーベースの仮想化技術の使用を通じて）、SFCの現在のモデルと実現により、サービスプロバイダーの柔軟性が低下し、頻繁に発生する管理の複雑さが増す可能性があります各SFFノードの（サービス）転送情報の変更。これは、SFP（および場合によってはネクストホップ情報）の変更には、適切な管理サイクルを実行する必要があるためです。
To address these challenges through a suitable solution, we identify the following requirements:
適切なソリューションを通じてこれらの課題に対処するために、以下の要件を特定します。
* Relations between Service Execution Points MUST be abstracted so that, from an SFP point of view, the Logical Path never changes.
* サービス実行ポイント間の関係は、SFPの観点から論理パスが変更されないように抽象化する必要があります。
* Deriving the Service Execution Points from the abstract SFP SHOULD be fast and incur minimum delay.
* 抽象SFPからサービス実行ポイントを取得することは高速で、最小限の遅延が発生する必要があります（SHOULD）。
* Identification of the Service Execution Points SHOULD NOT use a combination of Layer 2 or Layer 3 mechanisms.
* サービス実行ポイントの識別は、レイヤー2またはレイヤー3メカニズムの組み合わせを使用しないでください。
The next section outlines a solution to address the issue, allowing for keeping SFC information (represented in its SFP) intact while addressing the desired flexibility of the service provider.
次のセクションでは、この問題に対処するためのソリューションの概要を説明し、SFC情報（SFPで表される）をそのまま維持しながら、サービスプロバイダーの望ましい柔軟性に対処できるようにします。
The general idea is two pronged. Firstly, we elevate the definition of an SFP onto the level of "name-based interactions" rather than limiting SFPs to Layer 2 or Layer 3 information only. Secondly, we extend the operations of the SFF to allow for forwarding decisions that take into account such name-based interaction while remaining backward compatible to the current SFC architecture as defined in [RFC7665]. In the following sections, we outline these two components of our solution.
一般的な考え方は2つあります。まず、SFPをレイヤー2またはレイヤー3の情報のみに限定するのではなく、SFPの定義を「名前ベースの相互作用」のレベルに引き上げます。次に、SFFの操作を拡張して、[RFC7665]で定義されている現在のSFCアーキテクチャとの下位互換性を維持しながら、このような名前ベースの相互作用を考慮した決定を転送できるようにします。次のセクションでは、ソリューションのこれら2つのコンポーネントの概要を説明します。
If the next-hop information in the Network Locator Map (NLM) is described using an L2/L3 identifier, the name-based SFF (nSFF) may operate as described for (traditional) SFF, as defined in [RFC7665]. On the other hand, if the next-hop information in the NLM is described as a name, then the nSFF operates as described in the following sections.
ネットワークロケータマップ（NLM）のネクストホップ情報がL2 / L3識別子を使用して記述されている場合、名前ベースのSFF（nSFF）は、[RFC7665]で定義されている（従来の）SFFの説明に従って動作する場合があります。一方、NLMのネクストホップ情報が名前として記述されている場合、nSFFは次のセクションで説明するように動作します。
In the following sections, we outline the two components of our solution.
次のセクションでは、ソリューションの2つのコンポーネントの概要を説明します。
The existing SFC framework is defined in [RFC7665]. Section 4 outlines that the SFP information is representing path information based on Layer 2 or Layer 3 information, i.e., MAC or IP addresses, causing the aforementioned frequent adaptations in cases of execution-point changes. Instead, we introduce the notion of a "name-based Service Function Path (nSFP)".
既存のSFCフレームワークは[RFC7665]で定義されています。セクション4は、SFP情報がレイヤー2またはレイヤー3情報（MACアドレスまたはIPアドレス）に基づくパス情報を表し、実行ポイントが変更された場合に前述の頻繁な適応を引き起こすことを概説しています。代わりに、「名前ベースのサービス関数パス（nSFP）」の概念を紹介します。
In today's networking terms, any identifier can be treated as a name, but we will illustrate the realization of a "Name-based SFP" through extended SFF operations (see Section 6) based on URIs as names and HTTP as the protocol of exchanging information. Here, URIs are being used to name for an SF along the nSFP. Note that the nSFP approach is not restricted to HTTP (as the protocol) and URIs (as next-hop identifier within the SFP). Other identifiers such as an IP address itself can also be used and are interpreted as a "name" in the nSFP. IP addresses as well as fully qualified domain names forming complex URIs (uniform resource identifiers), such as www.example.com/ service_name1, are all captured by the notion of "name" in this document.
今日のネットワーキング用語では、任意の識別子を名前として扱うことができますが、URIを名前として、HTTPを情報交換プロトコルとして使用する拡張SFF操作（セクション6を参照）による「名前ベースのSFP」の実現を示します。ここでは、URIはnSFPに沿ったSFの名前に使用されています。 nSFPアプローチは、HTTP（プロトコル）およびURI（SFP内のネクストホップ識別子）に限定されないことに注意してください。 IPアドレス自体などの他の識別子も使用でき、nSFPでは「名前」として解釈されます。 IPアドレスと、www.example.com / service_name1などの複雑なURI（Uniform Resource Identifier）を形成する完全修飾ドメイン名はすべて、このドキュメントでは「名前」という概念でキャプチャされています。
Generally, nSFPs are defined as an ordered sequence of the "name" of SFs, and a typical nSFP may look like: 192.0.x.x -> www.example.com -> www.example2.com/service1 -> www.example2.com/service2.
一般に、nSFPはSFの「名前」の順序付けられたシーケンスとして定義され、一般的なnSFPは次のようになります。192.0.xx-> www.example.com-> www.example2.com/service1-> www.example2。 com / service2。
Our use case in Section 3 can then be represented as an ordered named sequence. An example for a session initiation that involves an authentication procedure, this could look like 192.0.x.x -> smf.example.org/session_initiate -> amf.example.org/auth -> smf.example.org/session_complete -> 192.0.x.x. (Note that this example is only a conceptual one since the exact nature of any future SBA-based exchange of 5G control-plane functions is yet to be defined by standardization bodies such as 3GPP).
セクション3のユースケースは、順序付けられた名前付きシーケンスとして表すことができます。認証手順を伴うセッション開始の例、これは192.0.xx-> smf.example.org/session_initiate-> amf.example.org/auth-> smf.example.org/session_complete-> 192.0のようになります。 xx （5Gコントロールプレーン機能の将来のSBAベースの交換の正確な性質は3GPPなどの標準化団体によってまだ定義されていないため、この例は概念的なものにすぎないことに注意してください）。
In accordance with our use case in Section 3, any of these named services can potentially be realized through more than one replicated SF instance. This leads to making dynamic decisions on where to send packets along the SAME SFP information, being provided during the execution of the SFC. Through elevating the SFP onto the notion of name-based interactions, the SFP will remain the same even if those specific execution points change for a specific service interaction.
セクション3の使用例によると、これらの名前付きサービスはすべて、複数の複製されたSFインスタンスを通じて潜在的に実現できます。これにより、SFCの実行中に提供されるSAME SFP情報に沿ってパケットを送信する場所を動的に決定できます。名前ベースの相互作用の概念にSFPを昇格させることにより、特定のサービス相互作用で特定の実行ポイントが変更されても、SFPは同じままです。
The following diagram in Figure 2 describes this nSFP concept and the resulting mapping of those named interactions onto (possibly) replicated instances.
図2の次の図は、このnSFPの概念と、（おそらく）複製されたインスタンスへの名前付き相互作用の結果のマッピングを示しています。
+---------------------------------------------------------------+
|Service Layer |
| 192.0.x.x --> www.example.com --> www.example2.com --> |
| || || |
+----------------------||--------------||-----------------------+
|| ||
|| ||
+----------------------||--------------||-----------------------+
|Underlay Network \/ \/ |
| +--+ +--+ +--+ +--+ +--+ +--+ |
| | | | | | | | | | | | | |
| +--+ +--+ +--+ +--+ +--+ +--+ |
| Compute and Compute and |
| storage nodes storage nodes |
+---------------------------------------------------------------+
Figure 2: Mapping SFC onto Service Function Execution Points along a Service Function Path Based on Virtualized Service Function Instance
図2：仮想化されたサービス関数インスタンスに基づくサービス関数パスに沿ったSFCのサービス関数実行ポイントへのマッピング
In order to forward a packet within an nSFP, we need to extend the NLM as defined in [RFC8300] with the ability to consider name relations based on URIs as well as high-level transport protocols such as HTTP for means of SFC packet forwarding. Another example for SFC packet forwarding could be that of Constrained Application Protocol (CoAP).
nSFP内でパケットを転送するには、[RFC8300]で定義されているようにNLMを拡張して、URIに基づく名前の関係や、SFCパケット転送の手段としてHTTPなどの高レベルのトランスポートプロトコルを考慮する必要があります。 SFCパケット転送の別の例は、制約付きアプリケーションプロトコル（CoAP）の例です。
The extended NLM or name-based Network Locator Map (nNLM) is shown in Table 1 as an example for www.example.com being part of the nSFP. Such extended nNLM is stored at each SFF throughout the SFC domain with suitable information populated to the nNLM during the configuration phase.
nSFPの一部であるwww.example.comの例として、拡張NLMまたは名前ベースのネットワークロケーターマップ（nNLM）を表1に示します。このような拡張nNLMは、構成フェーズ中にnNLMに適切な情報が入力された状態で、SFCドメイン全体の各SFFに格納されます。
+-----+-----+--------------------+------------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE) |
+=====+=====+====================+==============================+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
+-----+-----+--------------------+------------------------------+
| 10 | 254 | 198.51.100.10 | GRE |
+-----+-----+--------------------+------------------------------+
| 10 | 253 | www.example.com | HTTP |
+-----+-----+--------------------+------------------------------+
| 40 | 251 | 198.51.100.15 | GRE |
+-----+-----+--------------------+------------------------------+
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
+-----+-----+--------------------+------------------------------+
| 15 | 212 | Null (end of path) | None |
+-----+-----+--------------------+------------------------------+
Table 1: Name-Based Network Locator Map
表1：名前ベースのネットワークロケータマップ
Alternatively, the extended NLM may be defined with implicit name information rather than explicit URIs as in Table 1. In the example of Table 2, the next hop is represented as a generic HTTP service without a specific URI being identified in the extended NLM. In this scenario, the SFF forwards the packet based on parsing the HTTP request in order to identify the host name or URI. It retrieves the URI and may apply policy information to determine the destination host/service.
あるいは、拡張NLMは、表1のように明示的なURIではなく暗黙の名前情報で定義することもできます。表2の例では、ネクストホップは、拡張NLMで特定のURIが識別されていない一般的なHTTPサービスとして表されます。このシナリオでは、SFFは、ホスト名またはURIを識別するために、HTTP要求の解析に基づいてパケットを転送します。 URIを取得し、ポリシー情報を適用して宛先ホスト/サービスを決定します。
+-----+-----+--------------------+------------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE) |
+=====+=====+====================+==============================+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
+-----+-----+--------------------+------------------------------+
| 10 | 254 | 198.51.100.10 | GRE |
+-----+-----+--------------------+------------------------------+
| 10 | 253 | HTTP Service | HTTP |
+-----+-----+--------------------+------------------------------+
| 40 | 251 | 198.51.100.15 | GRE |
+-----+-----+--------------------+------------------------------+
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
+-----+-----+--------------------+------------------------------+
| 15 | 212 | Null (end of path) | None |
+-----+-----+--------------------+------------------------------+
Table 2: Name-Based Network Locator Map with Implicit Name Information
表2：暗黙的な名前情報を含む名前ベースのネットワークロケータマップ
It is desirable to extend the SFF of the SFC underlay to handle nSFPs transparently and without the need to insert any SF into the nSFP. Such extended nSFFs would then be responsible for forwarding a packet in the SFC domain as per the definition of the (extended) nSFP.
SFCアンダーレイのSFFを拡張して、nSFPを透過的に処理し、nSFPにSFを挿入する必要がないことが望ましいです。そのような拡張nSFFは、（拡張）nSFPの定義に従って、SFCドメインでパケットを転送する責任があります。
In our example realization for an extended SFF, the solution described in this document uses HTTP as the protocol of forwarding SFC packets to the next (name-based) hop in the nSFP. The URI in the HTTP transaction is the name in our nSFP information, which will be used for name-based forwarding.
拡張SFFの実現例では、このドキュメントで説明するソリューションは、SFCパケットをnSFPの次の（名前ベースの）ホップに転送するプロトコルとしてHTTPを使用します。 HTTPトランザクションのURIは、nSFP情報の名前であり、名前ベースの転送に使用されます。
Following our reasoning so far, HTTP requests (and more specifically, the plaintext-encoded requests above) are the equivalent of packets that enter the SFC domain. In the existing SFC framework, an IP payload is typically assumed to be a packet entering the SFC domain. This packet is forwarded to destination nodes using the L2 encapsulation. Any layer 2 network can be used as an underlay network. This notion is now extended to packets being possibly part of an entire higher-layer application such as HTTP requests. The handling of any intermediate layers, such as TCP and IP, is left to the realization of the (extended) SFF operations towards the next (named) hop. For this, we will first outline the general lifecycle of an SFC packet in the following subsection, followed by two examples for determining next-hop information in Section 6.2.3, finished up by a layered view on the realization of the nSFF in Section 6.2.4.
これまでの推論に従って、HTTP要求（より具体的には、上記の平文でエンコードされた要求）は、SFCドメインに入るパケットと同等です。既存のSFCフレームワークでは、IPペイロードは通常、SFCドメインに入るパケットであると想定されます。このパケットは、L2カプセル化を使用して宛先ノードに転送されます。レイヤー2ネットワークは、アンダーレイネットワークとして使用できます。この概念は、HTTPリクエストなどの上位層アプリケーション全体の一部である可能性があるパケットに拡張されています。 TCPやIPなどの中間層の処理は、次の（名前付き）ホップへの（拡張）SFF操作の実現に任されています。このため、最初に次のサブセクションでSFCパケットの一般的なライフサイクルの概要を説明し、次にセクション6.2.3でネクストホップ情報を決定する2つの例を示し、セクション6.2でnSFFの実現に関する階層化されたビューで終了します。 .4。
+----------+
| SF1 | +--------+ +------+
| instance |\ | NR | | SF2 |
+----------+ \ +--------+ +------+
\ || ||
+------------+ \ +-------+ +---------+ +---------+ +-------+
| Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 |
+------------+ +-------+ +---------+ +---------+ +-------+
||
+----------+
| Boundary |
| node |
+----------+
Figure 3: High-Level Architecture
図3：高レベルのアーキテクチャ
The high-level architecture for name-based operation shown in Figure 3 is very similar to the SFC architecture as described in [RFC7665]. Two new functions are introduced, as shown in the above diagram: namely, the nSFF and the Name Resolver (NR).
図3に示す名前ベースの操作の高レベルのアーキテクチャは、[RFC7665]で説明されているSFCアーキテクチャと非常に似ています。上の図に示すように、nSFFと名前リゾルバー（NR）という2つの新しい関数が導入されています。
The nSFF is an extension of the existing SFF and is capable of processing SFC packets based on nNLM information, determining the next SF where the packet should be forwarded, and the required transport encapsulation (TE). Like standard SFF operation, it adds TE to the SFC packet and forwards it.
nSFFは既存のSFFの拡張であり、nNLM情報に基づいてSFCパケットを処理し、パケットを転送する次のSFと必要なトランスポートカプセル化（TE）を決定できます。標準のSFF操作と同様に、TEをSFCパケットに追加して転送します。
The NR is a new functional component, capable of identifying the execution endpoints, where a "named SF" is running, triggered by suitable resolution requests sent by the nSFF. Though this is similar to DNS function, 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 serving the next hop of the SFP is used. The details are described later.
NRは、「名前付きSF」が実行されている実行エンドポイントを識別できる新しい機能コンポーネントであり、nSFFによって送信された適切な解決要求によってトリガーされます。これはDNS機能に似ていますが、同じではありません。 DNSプロトコルやデータレコードは使用しません。 SFPのネクストホップを提供するnSFFへの適切なルーティング/転送情報を決定する新しい手順が使用されます。詳細は後述します。
The other functional components, such as classifier and SF, are the same as described in SFC architecture, as defined in [RFC7665], while the Forwarders shown in the above diagram are traditional Layer 2 switches.
分類子やSFなどの他の機能コンポーネントは、[RFC7665]で定義されているSFCアーキテクチャで説明されているものと同じですが、上の図に示されているフォワーダーは従来のレイヤー2スイッチです。
In the proposed solution, the operations are realized by the name-based SFF, called "nSFF". We utilize the high-level architecture in Figure 3 to describe the traversal between two SF instances of an nSFP-based transaction in an example chain of: 192.0.x.x -> SF1 (www.example.com) -> SF2 (www.example2.com) -> SF3 -> ...
提案されたソリューションでは、操作は「nSFF」と呼ばれる名前ベースのSFFによって実現されます。図3の高レベルアーキテクチャを利用して、nSFPベースのトランザクションの2つのSFインスタンス間のトラバーサルを、192.0.xx-> SF1（www.example.com）-> SF2（www.example2）のチェーンの例で説明します。 .com）-> SF3-> ...
Service Function 3 (SF3) is assumed to be a classical SF; hence, existing SFC mechanisms can be used to reach it and will not be considered in this example.
サービス機能3（SF3）は従来のSFであると想定されています。したがって、既存のSFCメカニズムを使用してそれに到達でき、この例では考慮されません。
According to the SFC lifecycle, as defined in [RFC7665], based on our example chain above, the traffic originates from a classifier or another SFF on the left. The traffic is processed by the incoming nSFF1 (on the left side) through the following steps. The traffic exits at nSFF2.
[RFC7665]で定義されているSFCライフサイクルによれば、上記の例のチェーンに基づいて、トラフィックは左側の分類子または別のSFFから発信されます。トラフィックは、次の手順で着信nSFF1（左側）によって処理されます。トラフィックはnSFF2で存在します。
Step 1: At nSFF1, the following nNLM is assumed:
ステップ1：nSFF1では、次のnNLMが想定されています。
+-----+-----+--------------------+------------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE) |
+=====+=====+====================+==============================+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
+-----+-----+--------------------+------------------------------+
| 10 | 254 | 198.51.100.10 | GRE |
+-----+-----+--------------------+------------------------------+
| 10 | 253 | www.example.com | HTTP |
+-----+-----+--------------------+------------------------------+
| 10 | 252 | www.example2.com | HTTP |
+-----+-----+--------------------+------------------------------+
| 40 | 251 | 198.51.100.15 | GRE |
+-----+-----+--------------------+------------------------------+
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
+-----+-----+--------------------+------------------------------+
| 15 | 212 | Null (end of path) | None |
+-----+-----+--------------------+------------------------------+
Table 3: nNLM at nSFF1
表3：nSFF1のnNLM
Step 2: nSFF1 removes the previous transport encapsulation (TE) for any traffic originating from another SFF or classifier (traffic from an SF instance does not carry any TE and is therefore directly processed at the nSFF).
ステップ2：nSFF1は、別のSFFまたは分類子から発信されたトラフィックの以前のトランスポートカプセル化（TE）を削除します（SFインスタンスからのトラフィックはTEを伝送しないため、nSFFで直接処理されます）。
Step 3: nSFF1 then processes the Network Service Header (NSH) information, as defined in [RFC8300], to identify the next SF at the nSFP level by mapping the NSH information to the appropriate entry in its nNLM (see Table 3) based on the provided SPI/SI information in the NSH (see Section 4) in order to determine the name-based identifier of the next-hop SF. With such nNLM in mind, the nSFF searches the map for SPI = 10 and SI = 253. It identifies the next hop as = www.example.com and HTTP as the protocol to be used. Given that the next hop resides locally, the SFC packet is forwarded to the SF1 instance of www.example.com. Note that the next hop could also be identified from the provided HTTP request, if the next-hop information was identified as a generic HTTP service, as defined in Section 5.3.
ステップ3：nSFF1は、[RFC8300]で定義されているように、ネットワークサービスヘッダー（NSH）情報を処理し、NSH情報をnNLMの適切なエントリ（表3を参照）にマッピングして、nSFPレベルで次のSFを識別します。ネクストホップSFの名前ベースの識別子を決定するために、NSHで提供されるSPI / SI情報（セクション4を参照）。このようなnNLMを念頭に置いて、nSFFはマップでSPI = 10およびSI = 253を検索します。これにより、ネクストホップが= www.example.comとして識別され、HTTPが使用されるプロトコルとして識別されます。ネクストホップがローカルに存在する場合、SFCパケットはwww.example.comのSF1インスタンスに転送されます。セクション5.3で定義されているように、ネクストホップ情報が汎用HTTPサービスとして識別された場合、ネクストホップは提供されたHTTPリクエストからも識別できることに注意してください。
Step 4: The SF1 instance then processes the received SFC packet according to its service semantics and modifies the NSH by setting SPI = 10 and SI = 252 for forwarding the packet along the SFP. It then forwards the SFC packet to its local nSFF, i.e., nSFF1.
ステップ4：次に、SF1インスタンスは、受信したSFCパケットをそのサービスセマンティクスに従って処理し、SPIにパケットを転送するためにSPI = 10およびSI = 252を設定してNSHを変更します。次に、SFCパケットをローカルのnSFF、つまりnSFF1に転送します。
Step 5: nSFF1 processes the NSH of the SFC packet again, now with the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It retrieves the next-hop information from its nNLM in Table 3 to be www.example2.com. Due to this SF not being locally available, the nSFF consults any locally available information regarding routing/forwarding towards a suitable nSFF that can serve this next hop.
ステップ5：nSFF1は、SFCパケットのNSHを再度処理します。NSHはSF1インスタンスによって変更（SPI = 10、SI = 252）されています。表3のnNLMからネクストホップ情報を取得してwww.example2.comにします。このSFはローカルで利用できないため、nSFFは、この次のホップを提供できる適切なnSFFへのルーティング/転送に関するローカルで利用可能な情報を調べます。
Step 6: If such information exists, the Packet (plus the NSH information) is marked to be sent towards the nSFF serving the next hop based on such information in Step 8.
ステップ6：そのような情報が存在する場合、パケット（およびNSH情報）は、ステップ8でそのような情報に基づいて次のホップにサービスを提供するnSFFに送信されるようにマークされます。
Step 7: If such information does not exist, nSFF1 consults the NR to determine the suitable routing/forwarding information towards the identified nSFF serving the next hop of the SFP. For future SFC packets towards this next hop, such resolved information may be locally cached, avoiding contacting the NR for every SFC packet forwarding. The packet is now marked to be sent via the network in Step 8.
ステップ7：そのような情報が存在しない場合、nSFF1はNRを参照して、SFPのネクストホップを提供する識別されたnSFFへの適切なルーティング/転送情報を決定します。このネクストホップに向かう将来のSFCパケットの場合、そのような解決された情報はローカルにキャッシュされ、すべてのSFCパケット転送のNRへの接続を回避できます。これで、パケットはステップ8でネットワーク経由で送信されるようにマークされました。
Step 8: Utilizing the forwarding information determined in Steps 6 or 7, nSFF1 adds the suitable TE for the SFC packet before forwarding via the forwarders in the network towards the next nSFF22.
ステップ8：ステップ6または7で決定された転送情報を利用して、nSFF1はSFCパケットに適したTEを追加してから、ネットワーク内のフォワーダー経由で次のnSFF22に転送します。
Step 9: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, i.e., the nSFF serving the identified next hop of the SFP, it removes the TE and processes the NSH to identify the next-hop information. At nSFF2 the nNLM in Table 4 is assumed. Based on this nNLM and NSH information where SPI = 10 and SI = 252, nSFF2 identifies the next SF as www.example2.com.
ステップ9：パケット（+ NSH + TE）が発信nSFF2、つまり、SFPの識別されたネクストホップにサービスを提供するnSFFに到着すると、TEを削除し、NSHを処理してネクストホップ情報を識別します。 nSFF2では、表4のnNLMが想定されています。 SPI = 10およびSI = 252であるこのnNLMおよびNSH情報に基づいて、nSFF2は次のSFをwww.example2.comとして識別します。
+-----+-----+--------------------+------------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation (TE) |
+=====+=====+====================+==============================+
| 10 | 252 | www.example2.com | HTTP |
+-----+-----+--------------------+------------------------------+
| 40 | 251 | 198.51.100.15 | GRE |
+-----+-----+--------------------+------------------------------+
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
+-----+-----+--------------------+------------------------------+
| 15 | 212 | Null (end of path) | None |
+-----+-----+--------------------+------------------------------+
Table 4: nNLM at SFF2
表4：SFF2でのnNLM
Step 10: If the next hop is locally registered at the nSFF, it forwards the packet (+NSH) to the SF instance using suitable IP/MAC methods for doing so.
ステップ10：ネクストホップがnSFFでローカルに登録されている場合、適切なIP / MACメソッドを使用してパケット（+ NSH）をSFインスタンスに転送します。
Step 11: If the next hop is not locally registered at the nSFF, the outgoing nSFF adds new TE information to the packet and forwards the packet (+NSH+TE) to the next SFF or boundary node, as shown in Table 4.
ステップ11：ネクストホップがnSFFでローカルに登録されていない場合、発信nSFFは新しいTE情報をパケットに追加し、パケット（+ NSH + TE）を次のSFFまたは境界ノードに転送します（表4を参照）。
This section outlines the realization of various nSFF forwarding operations in Section 5.6. Although the operations in Section 5 utilize the notion of name-based transactions in general, we exemplify the operations here in Section 5 specifically for HTTP-based transactions to ground our description into a specific protocol for such name-based transaction. We will refer to the various steps in each of the following subsections.
このセクションでは、セクション5.6のさまざまなnSFF転送操作の実現について概説します。セクション5の操作は、一般に名前ベースのトランザクションの概念を利用しますが、ここでは特にセクション5の操作をHTTPベースのトランザクションに例示して、説明をそのような名前ベースのトランザクションの特定のプロトコルに基づいて説明します。以下の各サブセクションのさまざまなステップについて説明します。
Figure 4 shows the protocol layers based on the high-level architecture in Figure 3.
図4は、図3の高レベルアーキテクチャに基づくプロトコルレイヤーを示しています。
+-------+ +------+----+ +----+-----+
|App | | | | +--------+ | | |
|HTTP | |--------> | | NR | |nSFF----->|--
|TCP |->| TCP |nSFF| +---/\---+ | | TCP | |
|IP | | IP | | || | | IP | |
+-------+ +------+----+ +---------+ +---------+ +----------+ |
| L2 | | L2 |->|Forwarder|-->|Forwarder|-->| L2 | |
+-------+ +------+----+ +---------+ +---------+ +----------+ |
SF1 nSFF1 nSFF2 |
+-------+ |
| App |/ |
| HTTP | -----------+
| TCP |\
| IP |
| L2 |
+-------+
SF2
Figure 4: Protocol Layers
図4：プロトコル層
The nSFF component here is shown as implementing a full incoming/ outgoing TCP/IP protocol stack towards the local SFs, while implementing the nSFF-NR and nSFF-nSFF protocols based on the descriptions in Section 6.2.3.
ここのnSFFコンポーネントは、ローカルSFに向けて完全な着信/発信TCP / IPプロトコルスタックを実装する一方で、セクション6.2.3の説明に基づいてnSFF-NRおよびnSFF-nSFFプロトコルを実装するものとして示されています。
For the exchange of HTTP-based SF transactions, the nSFF terminates incoming TCP connections as well as outgoing TCP connections to local SFs, e.g., the TCP connection from SF1 terminates at nSFF1, and nSFF1 may store the connection information such as socket information. It also maintains the mapping information for the HTTP request such as originating SF, destination SF, and socket ID. nSFF1 may implement sending keep-alive messages over the socket to maintain the connection to SF1. Upon arrival of an HTTP request from SF1, nSFF1 extracts the HTTP Request and forwards it towards the next node as outlined in Section 6.2. Any returning response is mapped onto the suitable open socket (for the original request) and sent towards SF1.
HTTPベースのSFトランザクションの交換では、nSFFはローカルTCPへの送信TCP接続と同様に、着信TCP接続を終了します。たとえば、SF1からのTCP接続はnSFF1で終了し、nSFF1はソケット情報などの接続情報を保存できます。また、発信元SF、宛先SF、ソケットIDなどのHTTPリクエストのマッピング情報も保持します。 nSFF1は、SF1への接続を維持するために、ソケットを介したキープアライブメッセージの送信を実装できます。 SF1からHTTPリクエストが到着すると、セクション6.2で概説されているように、nSFF1はHTTPリクエストを抽出して次のノードに転送します。返された応答は、適切なオープンソケット（元の要求用）にマップされ、SF1に送信されます。
At the outgoing nSFF2, the destination SF2/Host is identified from the HTTP request message. If no TCP connection exists to the SF2, a new TCP connection is opened towards the destination SF2 and the HTTP request is sent over said TCP connection. The nSFF2 may also save the TCP connection information (such as socket information) and maintain the mapping of the socket information to the destination SF2. When an HTTP response is received from SF2 over the TCP connection, nSFF2 extracts the HTTP response, which is forwarded to the next node. nSFF2 may maintain the TCP connection through keep-alive messages.
発信nSFF2では、宛先SF2 / HostがHTTP要求メッセージから識別されます。 SF2へのTCP接続が存在しない場合、宛先のSF2に向けて新しいTCP接続が開かれ、HTTP要求がそのTCP接続を介して送信されます。 nSFF2は、TCP接続情報（ソケット情報など）を保存し、宛先SF2へのソケット情報のマッピングを維持することもできます。 TCP接続を介してSF2からHTTP応答を受信すると、nSFF2は次のノードに転送されるHTTP応答を抽出します。 nSFF2は、キープアライブメッセージを通じてTCP接続を維持できます。
In this section, we present three key aspects of operations for the realization of the steps in Section 5.6, namely, (i) the registration of local SFs (for Step 3 in Section 5.6), (ii) the forwarding of SFC packets to and from local SFs (for Steps 3, 4, and 10 in Section 5.6), (iii) the forwarding to a remote SF (for Steps 5, 6, and 7 in Section 5.6) and to the NR as well as (iv) for the lookup of a suitable remote SF (for Step 7 in Section 5.6). We also cover aspects of maintaining local lookup information for reducing lookup latency and other issues.
このセクションでは、セクション5.6のステップを実現するための操作の3つの主要な側面、つまり（i）ローカルSFの登録（セクション5.6のステップ3）、（ii）およびへのSFCパケットの転送について説明します。ローカルSF（セクション5.6のステップ3、4、および10の場合）、（iii）リモートSF（セクション5.6のステップ5、6、および7の場合）およびNRへの転送、および（iv）適切なリモートSFの検索（セクション5.6のステップ7用）。また、ルックアップの待ち時間やその他の問題を減らすために、ローカルのルックアップ情報を維持する側面についても説明します。
Forwarding between the distributed nSFFs as well as between nSFFs and NRs is realized over the operator network via a path-based approach. A path-based approach utilizes path information provided by the source of the packet for forwarding said packet in the network. This is similar to segment routing albeit differing in the type of information provided for such source-based forwarding as described in this section. In this approach, the forwarding information to a remote nSFF or the NR is defined as a "path identifier" (pathID) of a defined length where said length field indicates the full pathID length. The payload of the packet is defined by the various operations outlined in the following subsections, resulting in an overall packet being transmitted. With this, the generic forwarding format (GFF) for transport over the operator network is defined in Figure 5 with the length field defining the length of the pathID provided.
分散nSFF間およびnSFFとNR間の転送は、パスベースのアプローチを介して、オペレーターネットワーク上で実現されます。パスベースのアプローチは、ネットワークでパケットを転送するために、パケットのソースによって提供されるパス情報を利用します。これは、このセクションで説明するように、このようなソースベースの転送に提供される情報のタイプが異なるものの、セグメントルーティングに似ています。このアプローチでは、リモートnSFFまたはNRへの転送情報は、定義された長さの「パス識別子」（pathID）として定義されます。この長さフィールドは完全なパスIDの長さを示します。パケットのペイロードは、次のサブセクションで概説するさまざまな操作によって定義され、パケット全体が送信されます。これにより、オペレーター・ネットワークを介したトランスポート用の汎用転送フォーマット（GFF）が図5で定義され、長さフィールドが提供されたpathIDの長さを定義します。
+---------+-----------------+------------------------//------------+
| | | // |
| Length | Path ID | Payload // |
|(12 bits)| | // |
+---------+-----------------+--------------------//----------------+
Figure 5: Generic Forwarding Format (GFF)
図5：Generic Forwarding Format（GFF）
* Length (12 bits): Defines the length of the pathID, i.e., up to 4096 bits
* 長さ（12ビット）：パスIDの長さを定義します（最大4096ビット）。
* Path ID: Variable-length bit field derived from IPv6 source and destination address
* パスID：IPv6送信元および宛先アドレスから派生した可変長ビットフィールド
For the pathID information, solutions such as those in [Reed2016] can be used. Here, the IPv6 source and destination addresses are used to realize a so-called path-based forwarding from the incoming to the outgoing nSFF or the NR. The forwarders in Figure 4 are realized via SDN (software-defined networking) switches, implementing an AND/CMP operation based on arbitrary wildcard matching over the IPv6 source and destination addresses as outlined in [Reed2016]. Note that in the case of using IPv6 address information for path-based forwarding, the step of removing the TE at the outgoing nSFF in Figure 4 is realized by utilizing the provided (existing) IP header (which was used for the purpose of the path-based forwarding in [Reed2016]) for the purpose of next-hop forwarding such as that of IP-based routing. As described in Step 8 of the extended nSFF operations, this forwarding information is used as traffic encapsulation. With the forwarding information utilizing existing IPv6 information, IP headers are utilized as TE in this case. The next-hop nSFF (see Figure 4) will restore the IP header of the packet with the relevant IP information used to forward the SFC packet to SF2, or it will create suitable TE information to forward the information to another nSFF or boundary node. Forwarding operations at the intermediary forwarders, i.e., SDN switches, examine the pathID information through a flow-matching rule in which a specific switch-local output port is represented through the specific assigned bit position in the pathID. Upon a positive match in said rule, the packet is forwarded on said output port.
pathID情報については、[Reed2016]のようなソリューションを使用できます。ここでは、IPv6の送信元アドレスと宛先アドレスを使用して、着信から発信nSFFまたはNRへのいわゆるパスベースの転送を実現しています。図4のフォワーダーは、SDN（ソフトウェア定義ネットワーク）スイッチを介して実現され、[Reed2016]で概説されているように、IPv6送信元アドレスと宛先アドレスを介した任意のワイルドカード照合に基づくAND / CMP操作を実装します。パスベースの転送にIPv6アドレス情報を使用する場合、図4の発信nSFFでTEを削除するステップは、提供された（既存の）IPヘッダー（パスの目的で使用された）を利用することで実現されることに注意してください。 [Reed2016]のIPベースの転送）は、IPベースのルーティングなどのネクストホップ転送を目的としています。拡張nSFF操作のステップ8で説明したように、この転送情報はトラフィックのカプセル化として使用されます。この場合、既存のIPv6情報を利用した転送情報により、TEとしてIPヘッダーが利用されます。ネクストホップnSFF（図4を参照）は、SFCパケットをSF2に転送するために使用される関連IP情報でパケットのIPヘッダーを復元するか、適切なTE情報を作成して、情報を別のnSFFまたは境界ノードに転送します。中間フォワーダー、つまりSDNスイッチでの転送操作では、フローID内の特定の割り当てられたビット位置を通じて特定のスイッチローカル出力ポートが表されるフローマッチングルールを通じて、pathID情報を調べます。上記のルールが一致すると、パケットは上記の出力ポートに転送されます。
Alternatively, the solution in [BIER-MULTICAST] suggests using a so-called BIER (Binary Indexed Explicit Replication) underlay. Here, the nSFF would be realized at the ingress to the BIER underlay, injecting the SFC packet header (plus the Network Service Header (NSH)) with BIER-based traffic encapsulation into the BIER underlay with each of the forwarders in Figure 4 being realized as a so-called Bit-Forwarding Router (BFR) [RFC8279].
あるいは、[BIER-MULTICAST]のソリューションは、いわゆるBIER（Binary Indexed Explicit Replication）アンダーレイの使用を提案しています。ここで、nSFFはBIERアンダーレイへの入口で実現され、BIERベースのトラフィックカプセル化を備えたSFCパケットヘッダー（およびネットワークサービスヘッダー（NSH））がBIERアンダーレイに注入され、図4の各フォワーダーが実現されます。いわゆるビット転送ルーター（BFR）[RFC8279]として。
Given that the proposed solution operates at the "named-transaction" level, particularly for HTTP transactions, forwarding between nSFFs and/or NRs SHOULD be implemented via a transport protocol between nSFFs and/or NRs in order to provide reliability, segmentation of large GFF packets, and flow control, with the GFF in Figure 5 being the basic forwarding format for this.
提案されたソリューションが「名前付きトランザクション」レベルで、特にHTTPトランザクションで動作する場合、nSFFとNRの間の転送は、信頼性と大きなGFFのセグメンテーションを提供するために、nSFFとNRの間のトランスポートプロトコルを介して実装する必要があります（SHOULD）。パケットとフロー制御。図5のGFFは、このための基本的な転送形式です。
Note that the nSFFs act as TCP proxies at ingress and egress, thus terminating incoming and initiating outgoing HTTP sessions to SFs.
nSFFは入力と出力でTCPプロキシとして機能するため、SFへの着信および発信HTTPセッションを終了することに注意してください。
Figure 6 shows the packet format being used for the transmission of data, being adapted from the TCP header. Segmentation of large transactions into single transport protocol packets is realized through maintaining a "Sequence number". A "Checksum" is calculated over a single data packet with the ones-complement TCP checksum calculation being used. The "Window Size" field indicates the current maximum number of transport packets that are allowed in-flight by the egress nSFF. A data packet is sent without a "Data" field to indicate the end of the (e.g., HTTP) transaction.
図6は、データの送信に使用され、TCPヘッダーから適応されたパケット形式を示しています。大きなトランザクションを単一のトランスポートプロトコルパケットにセグメント化するには、「シーケンス番号」を維持します。 「チェックサム」は、1の補数のTCPチェックサム計算を使用して、単一のデータパケットに対して計算されます。 [ウィンドウサイズ]フィールドは、出力nSFFによって処理中のトランスポートパケットの現在の最大数を示します。データパケットは、「データ」フィールドなしで送信され、（HTTPなどの）トランザクションの終了を示します。
Note that, in order to support future named transactions based on other application protocols, such as Constrained Application Protocol (CoAP), future versions of the transport protocol MAY introduce a "Type" field that indicates the type of application protocol being used between SF and nSFF with "Type" 0x01 proposed for HTTP. This is being left for future study.
制約付きアプリケーションプロトコル（CoAP）などの他のアプリケーションプロトコルに基づく将来の名前付きトランザクションをサポートするために、トランスポートプロトコルの将来のバージョンでは、SFとSFの間で使用されているアプリケーションプロトコルのタイプを示す「タイプ」フィールドが導入される場合があります。 HTTPに提案された「タイプ」0x01のnSFF。これは将来の研究に残されています。
+----------------------------------------------+
| 16 bits | 16 bits |
+----------------------------------------------+
| Sequence number |
+----------------------------------------------+
| Checksum | Window Size |
+----------------------------------------------+
| ... |
| Data (Optional) |
+----------------------------------------------+
Figure 6: Transport Protocol Data Packet Format
図6：トランスポートプロトコルデータパケットの形式
Given the path-based forwarding being used between nSFFs, the transport protocol between nSFFs utilizes negative acknowledgements from the egress nSFF towards the ingress nSFF. The transport protocol negative Acknowledgment (NACK) packet carries the number of NACKs as well as the specific sequence numbers being indicated as lost in the "NACK number" field(s) as shown in Figure 7.
nSFF間でパスベースの転送が使用されているとすると、nSFF間のトランスポートプロトコルは、出力nSFFから入力nSFFへの否定応答を利用します。トランスポートプロトコルの否定応答（NACK）パケットは、図7に示すように、NACKの数と、「NACK番号」フィールドで失われたものとして示されている特定のシーケンス番号を伝達します。
+-----------------------+----------------------+
| 16 bits | 16 bits |
+----------------------------------------------+
| Number of NACKs | +
+----------------------------------------------+
| NACK number |
+----------------------------------------------+
+ ... NACK number +
+----------------------------------------------+
Figure 7: Transport Protocol NACK Packet Format
図7：トランスポートプロトコルNACKパケットの形式
If the indicated number of NACKs in a received NACK packet is nonzero, the ingress nSFF will retransmit all sequence numbers signaled in the packet while decreasing its congestion window size for future transmissions.
受信したNACKパケットのNACKの指定数がゼロ以外の場合、入力nSFFは、パケットでシグナリングされたすべてのシーケンス番号を再送信し、将来の送信のためにその輻輳ウィンドウサイズを縮小します。
If the indicated number of NACKs in a received NACK packet is zero, it will indicate the current congestion window as being successfully (and completely) being transmitted, increasing the congestion window size if smaller than the advertised "Window Size" in Figure 6.
受信したNACKパケットのNACKの指定数がゼロの場合、現在の輻輳ウィンドウが正常に（そして完全に）送信されていることを示し、図6でアドバタイズされた「ウィンドウサイズ」よりも小さい場合は、輻輳ウィンドウサイズを増やします。
The maintenance of the congestion window is subject to realization at the ingress nSFF and left for further study in nSFF realizations.
輻輳ウィンドウのメンテナンスは、入口nSFFでの実現を前提としており、nSFF実現のさらなる研究に残されています。
As outlined in Steps 3 and 10 of Section 5.6, the nSFF needs to determine if the SF derived from the Name-Based Network Locator (nNLM) is locally reachable or whether the packet needs to be forwarded to a remote SFF. For this, a registration mechanism is provided for such local SF with the local nSFF. Two mechanisms can be used for this:
セクション5.6のステップ3および10で概説したように、nSFFは、名前ベースのネットワークロケーター（nNLM）から派生したSFがローカルに到達可能かどうか、またはパケットをリモートSFFに転送する必要があるかどうかを決定する必要があります。このため、ローカルnSFFを使用して、このようなローカルSFの登録メカニズムが提供されます。これには2つのメカニズムを使用できます。
1. SF-initiated: We assume that the SF registers its Fully Qualified Domain Name (FQDN) to the local nSFF. As local mechanisms, we foresee that either a Representational State Transfer (REST-based) interface over the link-local link or configuration of the nSFF (through configuration files or management consoles) can be utilized. Such local registration events lead to the nSFF registering the given FQDN with the NR in combination with a system-unique nSFF identifier that is being used for path-computation purposes in the NR. For the registration, the packet format in Figure 8 is used (inserted as the payload in the GFF of Figure 5 with the pathID towards the NR).
1. SF開始：SFは完全修飾ドメイン名（FQDN）をローカルnSFFに登録すると想定しています。ローカルメカニズムとして、リンクローカルリンクを介したREST（Representational State Transfer）インターフェイスまたはnSFFの構成（構成ファイルまたは管理コンソールを使用）のいずれかを利用できると予測しています。このようなローカル登録イベントにより、nSFFは、NRでパス計算の目的で使用されているシステム固有のnSFF識別子と組み合わせて、指定されたFQDNをNRに登録します。登録には、図8のパケット形式が使用されます（NRへのパスIDとともに図5のGFFにペイロードとして挿入されます）。
+---------+------------------+----------------+
| | | |
| R/D | hash(FQDN) | nSFF_ID |
| (1 bit) | (16 bits) | (8 bits) |
+---------+------------------+----------------+
Figure 8: Registration Packet Format
図8：登録パケットの形式
+ R/D: 1-bit length (0 for Register, 1 for Deregister)
+ R / D：1ビット長（レジスタの場合は0、登録解除の場合は1）
+ hash(FQDN): 16-bit length for a hash over the FQDN of the SF
+ hash（FQDN）：SFのFQDN上のハッシュの16ビット長
+ nSFF_ID: 8-bit length for a system-unique identifier for the SFF related to the SF
+ nSFF_ID：SFに関連するSFFのシステム固有IDの8ビット長
We assume that the pathID towards the NR is known to the nSFF through configuration means.
NRへのパスIDは、構成手段を通じてnSFFに認識されていると想定しています。
The NR maintains an internal table that associates the hash(FQDN), the nSFF_id information, as well as the pathID information being used for communication between nSFFs and NRs. The nSFF locally maintains a mapping of registered FQDNs to IP addresses for the latter using link-local private IP addresses.
NRは、ハッシュ（FQDN）、nSFF_id情報、およびnSFFとNR間の通信に使用されるパスID情報を関連付ける内部テーブルを維持します。 nSFFは、リンクローカルプライベートIPアドレスを使用して、登録されたFQDNのIPアドレスへのマッピングをローカルで維持します。
2. Orchestration-based: In this mechanism, we assume that SFC to be orchestrated and the chain to be provided through an orchestration template with FQDN information associated to a compute/storage resource that is being deployed by the orchestrator. We also assume knowledge at the orchestrator of the resource topology. Based on this, the orchestrator can now use the same REST-based protocol defined in option 1 to instruct the NR to register the given FQDN, as provided in the template, at the nSFF it has identified as being the locally servicing nSFF, provided as the system-unique nSFF identifier.
2. オーケストレーションベース：このメカニズムでは、オーケストレーターによって展開されているコンピューティング/ストレージリソースに関連付けられたFQDN情報を含むオーケストレーションテンプレートを介して、SFCがオーケストレーションされ、チェーンが提供されると想定しています。また、リソーストポロジのオーケストレータでの知識も前提としています。これに基づいて、オーケストレーターは、オプション1で定義された同じRESTベースのプロトコルを使用して、テンプレートで提供された特定のFQDNを、ローカルサービスnSFFとして識別されたnSFFに登録するようにNRに指示できます。システム固有のnSFF識別子。
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 a packet to the SF (outgoing requests) as part of Steps 3 and 10 in Section 5.6. In the following, we outline the operation for HTTP as an example-named transaction.
ローカルSF転送には2つのケースがあります。つまり、SFCがローカルnSFFにSFCパケットを送信する（受信リクエスト）か、セクション5.6のステップ3と10の一部としてパケットをSFに送信する（送信リクエスト）nSFFです。以下では、名前付きトランザクションの例として、HTTPの操作の概要を説明します。
As shown in Figure 4, incoming HTTP requests from SFs are extracted by terminating the incoming TCP connection at their local nSFFs at the TCP level. The nSFF MUST maintain a mapping of open TCP sockets to HTTP requests (utilizing the URI of the request) for HTTP response association.
図4に示すように、SFからの着信HTTP要求は、TCPレベルのローカルnSFFで着信TCP接続を終了することによって抽出されます。 nSFFは、HTTP応答の関連付けのために、（要求のURIを使用して）開いているTCPソケットのHTTP要求へのマッピングを維持する必要があります。
For outgoing HTTP requests, the nSFF utilizes the maintained mapping of locally registered FQDNs to link-local IP addresses (see Section 6.2.2, option 1). Hence, upon receiving an SFC packet from a remote nSFF (in Step 9 of Section 5.6), the nSFF determines the local existence of the SF through the registration mechanisms in Section 6.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 Section 5.6 via a TCP-level connection. Outgoing nSFFs SHOULD keep TCP connections open to local SFs for improving SFC packet delivery in subsequent transactions.
発信HTTP要求の場合、nSFFはローカルに登録されたFQDNのリンクローカルIPアドレスへの維持されたマッピングを利用します（セクション6.2.2、オプション1を参照）。したがって、リモートnSFFからSFCパケットを受信すると（セクション5.6のステップ9で）、nSFFはセクション6.2.2の登録メカニズムを通じてSFのローカルな存在を決定します。上記のSFがローカルに存在する場合、HTTP（+ NSH）パケットは、TEを取り除いた後、TCPレベルの接続を介してセクション5.6のステップ10としてローカルSFに送信されます。発信nSFFは、後続のトランザクションでのSFCパケット配信を改善するために、ローカルSFへのTCP接続を開いたままにする必要があります（SHOULD）。
When executing Steps 3 and 10 in Section 5.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.
セクション5.6のステップ3と10を実行すると、SFCパケットはローカルに登録されたネクストホップに配信されます。 HTTPプロトコルの一部として、HTTP要求への応答は、元のnSFF（つまり、前のホップ）への戻りパスで配信される必要があります。このため、nSFFはリンクローカル接続情報のリスト、たとえばローカルSFへのソケットとリクエストが受信されたパスIDを維持します。応答を受信すると、nSFFはテーブルを参照して元の要求のパスIDを判別し、前のnSFFに返される適切なGFFベースのパケットを形成します。
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.
前のnSFFでHTTP応答を受信すると、nSFFは（ローカルで）開いているソケットのテーブルを参照して適切なローカルSF接続を決定し、受信したHTTP応答URIを格納されている要求URIにマッピングします。見つかったソケットを利用して、HTTP応答はローカルに登録されたSFに転送されます。
In Steps 5, 6, 7, and 8 of Section 5.6, an SFC packet is forwarded to a remote nSFF based on the nNLM information for the next hop of the nSFP. Section 6.2.5.1 handles the case of suitable forwarding information to the remote nSFF not existing, therefore consulting the NR to obtain suitable information. Section 6.2.5.2 describes the maintenance of forwarding information at the local nSFF. Section 6.2.5.3 describes the update of stale forwarding information. Note that the forwarding described in Section 6.2.1 is used for the actual forwarding to the various nSFF components. Ultimately, Section 6.2.5.4 describes the forwarding to the remote nSFF via the forwarder network.
セクション5.6のステップ5、6、7、および8では、SFCパケットは、nSFPの次のホップのnNLM情報に基づいてリモートnSFFに転送されます。セクション6.2.5.1は、リモートnSFFへの適切な転送情報が存在しない場合を処理するため、NRに問い合わせて適切な情報を取得します。セクション6.2.5.2では、ローカルnSFFでの転送情報の維持について説明します。 6.2.5.3項では、古い転送情報の更新について説明します。セクション6.2.1で説明されている転送は、さまざまなnSFFコンポーネントへの実際の転送に使用されることに注意してください。最終的に、セクション6.2.5.4は、フォワーダネットワークを介したリモートnSFFへの転送について説明しています。
The nSFF communicates with the NR for two purposes: namely, the registration and discovery of FQDNs. The packet format for the former was shown in Figure 8 in Section 6.2.2, while Figure 9 outlines the packet format for the discovery request.
nSFFは、FQDNの登録と検出という2つの目的でNRと通信します。前者のパケット形式をセクション6.2.2の図8に示し、図9にディスカバリ要求のパケット形式の概要を示します。
+--------------+-------------+ +--------+-----------------//--------+
| | | | | // |
| hash(FQDN) | nSFF_ID | | Length | pathID // |
| (16 bits) | (8 bits) | |(4 bits)| // |
+--------------+-------------+ +--------+-------------//------------+
Path Request Path Response
Figure 9: Discovery Packet Format
図9：検出パケットの形式
For Path Request:
パス要求の場合：
* hash(FQDN): 16-bit length for a hash over the FQDN of the SF
* hash（FQDN）：SFのFQDN上のハッシュの16ビット長
* nSFF_ID: 8-bit length for a system-unique identifier for the SFF related to the SF
* nSFF_ID：SFに関連するSFFのシステム固有IDの8ビット長
For Path Response:
パス応答の場合：
* Length: 4-bit length that defines the length of the pathID
* 長さ：pathIDの長さを定義する4ビットの長さ
* Path ID: Variable-length bit field derived from IPv6 source and destination address
* パスID：IPv6送信元および宛先アドレスから派生した可変長ビットフィールド
A path to a 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 length identifier. The NR SHOULD maintain a table of discovery 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 the discovery request.
特定のFQDNへのパスは、FQDNのハッシュをそのnSFF_idとともにNRに送信し、長さ識別子を持つパスIDを応答として受信することによって要求されます。 NRは、発見された（ハッシュ）FQDNを、それを要求したnSFF_idと発見要求の結果として計算されているパスIDにマップする発見要求のテーブルを維持する必要があります（SHOULD）。
The discovery request for an FQDN that has not previously been served at the nSFF (or for an FQDN whose pathID information has been flushed as a result of the update operations in Section 6.2.5.3) results in an initial latency incurred by this discovery through the NR, while any SFC packet sent over the same SFP in a subsequent transaction will utilize the nSFF-local mapping table. Such initial latency can be avoided by prepopulating the FQDN-pathID mapping proactively as part of the overall orchestration procedure, e.g., alongside the distribution of the nNLM information to the nSFF.
以前nSFFで提供されていなかったFQDN（またはセクション6.2.5.3の更新操作の結果としてpathID情報がフラッシュされたFQDN）のディスカバリリクエストにより、このディスカバリによって発生する初期遅延がNR。その後のトランザクションで同じSFPを介して送信されるSFCパケットは、nSFFローカルマッピングテーブルを利用します。このような初期レイテンシは、オーケストレーション手順全体の一部として、たとえばnNLM情報のnSFFへの配布と並行して、FQDN-pathIDマッピングを事前に入力することで回避できます。
Each nSFF MUST maintain an internal table that maps the (hash of the) FQDN information to a suitable pathID. As outlined in Step 7 of Section 5.6, if a suitable entry does not exist for a given FQDN, the pathID information is requested with the operations in Section 6.2.5.1 and the suitable entry is locally created upon receiving a reply with the forwarding operation being executed as described in Section 6.2.1.
各nSFFは、FQDN情報（のハッシュ）を適切なパスIDにマップする内部テーブルを維持する必要があります。セクション5.6のステップ7で概説されているように、特定のFQDNに適切なエントリが存在しない場合は、セクション6.2.5.1の操作でpathID情報が要求され、適切なエントリが転送操作で応答を受信するとローカルに作成されます6.2.1項の説明に従って実行されます。
If such an entry does exist (i.e., Step 6 of Section 5.6), the pathID is locally retrieved and used for the forwarding operation in Section 6.2.1.
そのようなエントリが存在する場合（つまり、セクション5.6のステップ6）、pathIDはローカルに取得され、セクション6.2.1の転送操作に使用されます。
The forwarding information maintained at each nSFF (see Section 6.2.5.2) might need to be updated for three reasons:
各nSFF（セクション6.2.5.2を参照）で保持されている転送情報は、次の3つの理由で更新が必要になる場合があります。
1. An existing SF is no longer reachable: In this case, the nSFF with which the SF is locally registered deregisters the SF explicitly at the NR by sending the packet in Figure 6 with the hashed FQDN and the R/D bit set to 1 (for deregister).
1. 既存のSFに到達できなくなった：この場合、SFがローカルに登録されているnSFFは、ハッシュされたFQDNとR / Dビットを1に設定して、図6のパケットを送信して、NRで明示的にSFの登録を解除します（登録解除）。
2. Another SF instance has become reachable in the network (and, therefore, might provide a better alternative to the existing SF): In this case, the NR has received another packet with a format defined in Figure 7 but a different nSFF_id value.
2. 別のSFインスタンスがネットワークで到達可能になりました（したがって、既存のSFのより良い代替手段となる可能性があります）：この場合、NRは、図7で定義されたフォーマットで異なるnSFF_id値を持つ別のパケットを受信しました。
3. Links along paths might no longer be reachable: The NR might use a suitable southbound interface to transport networks to detect link failures, which it associates to the appropriate pathID bit position.
3. パスに沿ったリンクに到達できなくなる可能性があります。NRは適切なサウスバウンドインターフェイスを使用してネットワークを転送し、適切なpathIDビット位置に関連付けられているリンク障害を検出します。
For this purpose, the packet format in Figure 10 is sent from the NR to all affected nSFFs, using the generic format in Figure 5.
この目的のために、図10のパケット形式は、図5の一般的な形式を使用して、NRから影響を受けるすべてのnSFFに送信されます。
+---------+-----------------+--------------//----+
| | | // |
| Type | #IDs | IDs // |
| (1 bit) | (8 bits) | // |
+---------+-----------------+----------//--------+
Figure 10: Path Update Format
図10：パス更新フォーマット
* Type: 1-bit length (0 for Nsff ID, 1 for Link ID)
* タイプ：1ビット長（Nsff IDの場合は0、リンクIDの場合は1）
* #IDs: 8-bit length for number of IDs in the list
* IDs: List of IDs (Nsff ID or Link ID)
* ID：IDのリスト（Nsff IDまたはリンクID）
The pathID to the affected nSFFs is computed as the binary OR over all pathIDs to those nSFF_ids affected where the pathID information to the affected nSFF_id values is determined from the NR-local table maintained in the registration/deregistration operation of Section 6.2.2.
影響を受けるnSFFへのpathIDは、影響を受けるnSFF_idへのすべてのpathIDのバイナリORとして計算されます。影響を受けるnSFF_id値へのpathID情報は、セクション6.2.2の登録/登録解除操作で維持されるNRローカルテーブルから決定されます。
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 cases 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 sent SF discovery requests, utilizing the optional 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 all nSFFs. Upon receiving the path update at the affected nSFF, all appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) identifiers provided will be removed, leading to a new NR discovery request at the next remote nSFF forwarding to the appropriate FQDN.
ケース1および2の場合、タイプビットは1（タイプnSFF_id）に設定され、影響を受けるnSFFは、以前に登録されたFQDNをnSFF_id値にマッピングするオプションのテーブルを利用して、以前にSF検出要求を送信したnSFFによって決定されます。 FQDN（のハッシュ）をnSFF_idにマッピングするテーブルが維持されていない場合、更新はすべてのnSFFに送信されます。影響を受けるnSFFでパスの更新を受信すると、提供されたハッシュ（FQDN）識別子のパスIDへの適切なすべてのnSFFローカルマッピングエントリが削除され、次のリモートnSFFで新しいNR検出要求が適切なFQDNに転送されます。
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 previously resulted in pathIDs that include the affected link, utilizing the optional table mapping previously registered FQDNs to pathID values (see Section 6.2.5.1). Upon receiving the node identifier information in the path update, the affected nSFF will check its internal table that maps FQDNs to pathIDs to determine those pathIDs affected by the link problems and remove path information that includes the received node identifier(s). For this, the pathID entries of said table are checked against the linkID values provided in the ID entry of the path update through a binary AND/CMP operation to check the inclusion of the link in the pathIDs 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.
ケース3では、タイプビットが0（タイプリンクID）に設定され、影響を受けるnSFFは、以前に登録されたFQDNをパスID値にマッピングするオプションのテーブルを利用して、影響を受けるリンクを含むパスIDを以前に検出要求したnSFFによって決定されます（セクション6.2.5.1を参照してください）。パスの更新でノード識別子情報を受信すると、影響を受けるnSFFは、FQDNをパスIDにマップする内部テーブルをチェックして、リンクの問題の影響を受けるパスIDを特定し、受信したノード識別子を含むパス情報を削除します。このために、上記のテーブルのpathIDエントリは、パスのIDエントリで提供されたlinkID値に対してバイナリAND / CMP操作を通じてチェックされ、FQDNへのpathIDにリンクが含まれているかどうかがチェックされます。 pathIDが影響を受ける場合、FQDN-pathIDエントリが削除され、次のリモートnSFFで新しいNR検出要求が適切なFQDNに転送されます。
Once Steps 5, 6, and 7 in Section 5.6 are being executed, Step 8 finally sends the SFC packet to the remote nSFF, utilizing the pathID returned in the discovery request (Section 6.2.5.1) or retrieved from the local pathID mapping table. The SFC packet is placed in the payload of the generic forwarding format in Figure 5 together with the pathID, and the nSFF eventually executes the forwarding operations in Section 6.2.1.
セクション5.6のステップ5、6、および7が実行されると、ステップ8は、ディスカバリ要求（セクション6.2.5.1）で返された、またはローカルパスIDマッピングテーブルから取得されたパスIDを利用して、最後にSFCパケットをリモートnSFFに送信します。 SFCパケットは、pathIDとともに図5の汎用転送フォーマットのペイロードに配置され、nSFFは最終的にセクション6.2.1の転送操作を実行します。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Sections 5 and 6 describe the forwarding of SFC packets between named SFs based on URIs exchanged in HTTP messages. Security is needed to protect the communications between originating node and Ssff, between one Nsff and the next Nsff, and between Nsff and destination. TLS is sufficient for this and SHOULD be used. The TLS handshake 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.
セクション5および6では、HTTPメッセージで交換されるURIに基づいて、名前付きSF間のSFCパケットの転送について説明します。発信ノードとSsffの間、1つのNsffと次のNsffの間、およびNsffと宛先の間の通信を保護するには、セキュリティが必要です。これにはTLSで十分であり、使用する必要があります（SHOULD）。 TLSハンドシェイクによりFQDNを決定できます。これは、サービスルーティングの決定に十分です。 TLSのサポートにより、HTTPSベースのトランザクションの可能性も可能になります。
It should be noted (per [RFC3986]) that what a URI resolves to is not necessarily stable. This can allow flexibility in deployment, as described in this document, but may also result in unexpected behavior and could provide an attack vector as the resolution of a URI could be "hijacked" resulting in packets being steered to the wrong place. This could be particularly important if the SFC is intended to send packets for processing at security functions. Such hijacking is a new attack surface introduced by using a separate NR.
（[RFC3986]に従って）URIが解決するものが必ずしも安定しているわけではないことに注意する必要があります。これにより、このドキュメントで説明されているように展開に柔軟性を持たせることができますが、予期しない動作が発生したり、URIの解決が「ハイジャック」されてパケットが誤った場所に誘導される可能性があるため、攻撃ベクトルが提供される可能性があります。これは、SFCがセキュリティ機能での処理のためにパケットを送信することを目的としている場合に特に重要です。このようなハイジャックは、別のNRを使用することによって導入された新しい攻撃面です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279] Wijnands、IJ。、Ed。、Rosen、E.、Ed。、Dolganow、A.、Przygienda、T.、and S. Aldrin、 "Multicast Using Bit Index Explicit Replication（BIER）"、RFC 8279、DOI 10.17487 / RFC8279、2017年11月、<https://www.rfc-editor.org/info/rfc8279>。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、Ed。、and C. Pignataro、Ed。、 "Network Service Header（NSH）"、RFC 8300、DOI 10.17487 / RFC8300、January 2018、<https： //www.rfc-editor.org/info/rfc8300>。
[BIER-MULTICAST] Trossen, D., Rahman, A., Wang, C., and T. Eckert, "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Work in Progress, Internet-Draft, draft-ietf-bier-multicast-http-response-01, 28 June 2019, <https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-01>.
[BIER-MULTICAST] Trossen、D.、Rahman、A.、Wang、C。、およびT. Eckert、「適応ストリーミングサービスに対するBIERマルチキャストオーバーレイの適用性」、進行中の作業、インターネットドラフト、draft-ietf-bier -multicast-http-response-01、2019年6月28日、<https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-01>。
[Reed2016] Reed, M.J., Al-Naday, M., Thomas, N., Trossen, D., Petropoulos, G., and S. Spirou, "Stateless multicast switching in software defined networks", IEEE ICC 2016, DOI 10.1109/ICC.2016.7511036, May 2016, <https://ieeexplore.ieee.org/document/7511036>.
[Reed2016] Reed、MJ、Al-Naday、M.、Thomas、N.、Trossen、D.、Petropoulos、G。、およびS. Spirou、「ソフトウェア定義ネットワークにおけるステートレスマルチキャストスイッチング」、IEEE ICC 2016、DOI 10.1109 /ICC.2016.7511036、2016年5月、<https://ieeexplore.ieee.org/document/7511036>。
[Schlinker2017] Schlinker, B., Kim, H., Cui, T., Katz-Bassett, E., Madhyastha, H., Cunha, I., Quinn, J., Hassan, S., Lapukhov, P., and H. Zeng, "Engineering Egress with Edge Fabric, Steering Oceans of Content to the World", ACM SIGCOMM 2017, August 2017, <https://research.fb.com/wp-content/uploads/2017/08/sigcomm17-final177-2billion.pdf>.
[Schlinker2017] Schlinker、B.、Kim、H.、Cui、T.、Katz-Bassett、E.、Madhyastha、H.、Cunha、I.、Quinn、J.、Hassan、S.、Lapukhov、P。、 H. Zeng、「エッジファブリックによるエンジニアリング出力、コンテンツの世界へのステアリング」、ACM SIGCOMM 2017、2017年8月、<https://research.fb.com/wp-content/uploads/2017/08/sigcomm17 -final177-2billion.pdf>。
[SDO-3GPP-SBA] 3GPP, "Technical Realization of Service Based Architecture", 3GPP TS 29.500 V15.5.0, September 2019, <https://www.3gpp.org/ftp/Specs/html-info/29500.htm>.
[SDO-3GPP-SBA] 3GPP、「Technical Realization of Service Based Architecture」、3GPP TS 29.500 V15.5.0、2019年9月、<https://www.3gpp.org/ftp/Specs/html-info/29500.htm >。
[SDO-3GPP-SBA-ENHANCEMENT] 3GPP, "New SID for Enhancements to the Service-Based 5G System Architecture", 3GPP S2-182904, February 2018, <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/ TSGS2_126_Montreal/Docs/S2-182904.zip>.
[SDO-3GPP-SBA-ENHANCEMENT] 3GPP、「サービスベースの5Gシステムアーキテクチャの拡張のための新しいSID」、3GPP S2-182904、2018年2月、<https://www.3gpp.org/ftp/tsg_sa/WG2_Arch / TSGS2_126_Montreal / Docs / S2-182904.zip>。
Acknowledgements
謝辞
The authors would like to thank Dirk von Hugo and Andrew Malis for their reviews and valuable comments. We would also like to thank Joel Halpern, the chair of the SFC WG, and Adrian Farrel for guiding us through the Independent Submission Editor (ISE) path.
著者は、レビューと貴重なコメントを提供してくれたDirk von HugoとAndrew Malisに感謝します。また、SFC WGの議長であるJoel Halpern氏、およびIndependent Submission Editor（ISE）パスを案内してくれたAdrian Farrel氏にも感謝します。
Authors' Addresses
著者のアドレス
Dirk Trossen InterDigital Europe, Ltd 64 Great Eastern Street, 1st Floor London EC2A 3QR United Kingdom
Dirk Trossen InterDigital Europe、Ltd 64 Great Eastern Street、1st Floor London EC2A 3QR United Kingdom
Email: Dirk.Trossen@InterDigital.com
Debashish Purkayastha InterDigital Communications, LLC 1001 E Hector St Conshohocken, PA United States of America
Debashish Purkayastha InterDigital Communications、LLC 1001 E Hector St Conshohocken、PAアメリカ合衆国
Email: Debashish.Purkayastha@InterDigital.com
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal Canada
Akbar Rahman InterDigital Communications、LLC 1000 Sherbrooke Street West Montreal Canada
Email: Akbar.Rahman@InterDigital.com