RFC 8979 - Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8979.html
タイトル : RFC 8979 - ネットワークサービスヘッダ（NSH）内のサブスクライバとパフォーマンスポリシー識別子コンテキストヘッダ
翻訳編集 : 自動生成

[要約] RFC 8979は、ネットワークサービスヘッダー(NSH)内での加入者およびパフォーマンスポリシー識別子コンテキストヘッダーに関するものです。この文書の目的は、ネットワーク内でのサービス品質(QoS)やセキュリティポリシーの適用を効率的に行うために、特定の加入者やトラフィックフローを識別するための方法を提供することです。利用場面としては、サービスプロバイダーが顧客ごとにカスタマイズされたネットワークサービスを提供する際や、ネットワークのパフォーマンスを最適化するためのポリシー適用などが挙げられます。

Internet Engineering Task Force (IETF)                       B. Sarikaya
Request for Comments: 8979
Category: Standards Track                                    D. von Hugo
ISSN: 2070-1721                                         Deutsche Telekom
                                                            M. Boucadair
                                                                  Orange
                                                           February 2021

Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)

ネットワークサービスヘッダ（NSH）内のサブスクライバとパフォーマンスポリシー識別子コンテキストヘッダ

Abstract

概要

This document defines the Subscriber and Performance Policy Identifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriate Service Function Chaining (SFC) operations. The structure of each Context Header and their use and processing by NSH-aware nodes are described.

このドキュメントは、サブスクライバとパフォーマンスポリシー識別子コンテキストヘッダーを定義します。これらの可変長コンテキストヘッダは、ネットワークサービスヘッダ（NSH）で実行することができ、ポリシー施行および適切なサービス機能連鎖（SFC）操作のために、加入者および性能関連情報のサービス機能（SFS）を通知するために使用されます。。各コンテキストヘッダの構造とNSH対応ノードによるその使用と処理について説明します。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、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/rfc8979.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8979で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Conventions and Terminology
   3.  Subscriber Identifier NSH Variable-Length Context Header
   4.  Performance Policy Identifier NSH Variable-Length Context
           Headers
   5.  MTU Considerations
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

This document discusses how to inform Service Functions (SFs) [RFC7665] about subscriber and service policy information when required for the sake of policy enforcement within a single administrative domain. In particular, subscriber-related information may be required to enforce subscriber-specific SFC-based traffic policies. However, the information carried in packets may not be sufficient to unambiguously identify a subscriber. This document fills this void by specifying a new Network Service Header (NSH) [RFC8300] Context Header to convey and disseminate such information within the boundaries of a single administrative domain. As discussed in Section 3, the use of obfuscated and non-persistent identifiers is recommended.

この文書では、1人の管理ドメイン内のポリシー施行のために必要な場合は、購読者およびサービスポリシー情報に関するサービス機能（SFS）[RFC7665]に関する情報について説明します。特に、加入者関連の情報が、加入者固有のSFCベースのトラフィックポリシーを強制することが要求される場合があります。しかしながら、パケット内で運ばれる情報は、加入者を明確に識別するのに十分ではないかもしれない。このドキュメントは、単一の管理ドメインの境界内で新しいネットワークサービスヘッダ（NSH）[RFC8300]コンテキストヘッダを指定して、そのような情報を伝達して普及させることで、このvoidをいっぱいにします。セクション3で説明したように、難読化および非永続識別子の使用をお勧めします。

Also, traffic steering by means of SFC may be driven, for example, by Quality of Service (QoS) considerations. Typically, QoS information may serve as an input for the computation, establishment, and selection of the Service Function Path (SFP). Furthermore, the dynamic structuring of Service Function Chains and their subsequent SFPs may be conditioned by QoS requirements that will affect the identification, location, and sequencing of SF instances. Hence, the need arises to provide downstream SFs with a performance policy identifier in order for them to appropriately meet the QoS requirements. This document also specifies a new NSH Context Header (Section 4) to convey such policy identifiers.

また、SFCによるトラフィック操縦は、例えば、サービス品質（QoS）考慮事項によって駆動され得る。典型的には、QoS情報は、サービス機能経路（SFP）の計算、確立、および選択のための入力として機能することができる。さらに、サービス関数チェーンとその後続のSFPの動的構造化は、SFインスタンスの識別、場所、および順序付けに影響を与えるQoS要件によって調整され得る。したがって、それらがQoS要件を適切に満たすために、パフォーマンスポリシー識別子を用いて下流のSFSを提供する必要が生じる。この文書は、そのようなポリシー識別子を伝達するための新しいNSHコンテキストヘッダ（セクション4）も指定されています。

The context information defined in this document can be applicable in the context of mobile networks (particularly in the 3GPP-defined (S)Gi interface) [CASE-MOBILITY]. Typically, because of the widespread use of private IPv4 addresses in those networks, if the SFs to be invoked are located after a NAT function, the identification based on the internal IPv4 address is not possible once the NAT has been crossed. NAT functionality can reside in a distinct node. For a 4G 3GPP network, that node can be the Packet Data Network (PDN) Gateway (PGW) as specified in [TS23401]. For a 5G 3GPP network, it can be the User Plane Function (UPF) facing the external Data Network (DN) [TS23501]. As such, a mechanism to pass the internal information past the NAT boundary may optimize packet traversal within an SFC-enabled mobile network domain. Furthermore, some SFs that are not enabled on the PGW/UPF may require a subscriber identifier to properly operate (see, for example, those listed in [RFC8371]). It is outside the scope of this document to include a comprehensive list of deployments that may make use of the Context Headers defined in the document.

この文書で定義されているコンテキスト情報は、モバイルネットワーク（特に3GPP定義（S）GIインタフェース）[ケースモビリティ]のコンテキストに適用できます。通常、それらのネットワーク内のプライベートIPv4アドレスの広範な使用のために、呼び出されるSFSがNAT関数の後に配置されている場合、NATがクロスされたら、内部IPv4アドレスに基づく識別は不可能です。 NAT機能は異なるノードに存在できます。 4G 3GPPネットワークの場合、そのノードは[TS23401]で指定されているようにパケットデータネットワーク（PGW）ゲートウェイ（PGW）にすることができます。 5G 3GPPネットワークでは、外部データネットワーク（DN）[TS23501]に直面しているユーザープレーン機能（UPF）です。したがって、NAT境界を通過する内部情報を通過させるメカニズムは、SFC対応モバイルネットワークドメイン内のパケットトラバースを最適化することができる。さらに、PGW / UPFで有効になっていないSFSの中には、加入者識別子が適切に動作する必要があります（たとえば、[RFC8371]にリストされているもの）。この文書の範囲外には、文書内に定義されているコンテキストヘッダーを利用できる展開の包括的なリストが含まれています。

Since subscriber identifiers are distinct from those used to identify a performance policy and given that multiple policies may be associated with a single subscriber within a Service Function Chain, these identifiers are carried in distinct Context Headers rather than being multiplexed in one single Context Header. This approach avoids a requirement for additional internal structure in the Context Headers to specify whether an identifier refers to a subscriber or to a policy.

加入者識別子は、パフォーマンスポリシーを識別するために使用され、複数のポリシーがサービス機能チェーン内の単一の購読者に関連付けられていることを考えるものとは異なるため、これらの識別子は1つのシングルコンテキストヘッダーに多重化されているのではなく、異なるコンテキストヘッダーで搬送されます。このアプローチは、コンテキストヘッダ内の追加の内部構造に対する要件を回避して、識別子が加入者またはポリシーを指すかどうかを指定する。

This document does not make any assumptions about the structure of subscriber or performance policy identifiers; each such identifier is treated as an opaque value. The semantics and validation of these identifiers are policies local to each SFC-enabled domain. This document focuses on the data plane behavior. Control plane considerations are out of the scope.

この文書は、加入者またはパフォーマンスポリシー識別子の構造についての仮定をしません。そのような各識別子は不透明値として扱われる。これらの識別子のセマンティクスと検証は、各SFC対応ドメインのローカルのポリシーです。この文書はデータプレーンの動作に焦点を当てています。制御面の考慮事項は範囲外です。

This document adheres to the SFC data plane architecture defined in [RFC7665]. This document assumes the reader is familiar with [RFC8300].

この文書は[RFC7665]で定義されているSFCデータプレーンアーキテクチャに準拠しています。この文書はリーダーが[RFC8300]に精通していることを前提としています。

This document assumes the NSH is used exclusively within a single administrative domain. This document follows the recommendations in [RFC8300] for handling the Context Headers at both ingress and egress SFC boundary nodes (i.e., to strip the entire NSH, including Context Headers). Revealing any subscriber-related information to parties outside the SFC-enabled domain is avoided by design. Accordingly, the scope for privacy breaches and user tracking is limited to within the SFC-enabled domain where the NSH is used. It is assumed that appropriate mechanisms to monitor and audit an SFC-enabled domain to detect misbehavior and to deter misuse are in place.

このドキュメントは、NSHが単一の管理ドメイン内で排他的に使用されていることを前提としています。このドキュメントは、入力および出力SFC境界ノードの両方でコンテキストヘッダーを処理するための[RFC8300]の推奨事項に従います（すなわち、コンテキストヘッダを含むNSH全体を削除する）。SFC対応ドメインの外部の締約国への加入者関連情報を明らかにすることは、設計によって回避されます。したがって、プライバシー侵害およびユーザー追跡の範囲は、NSHが使用されているSFC対応ドメイン内に制限されています。SFC対応ドメインを監視および監査するための適切なメカニズムは、不正行為を検出し、誤用を妨害することが整っていると仮定する。

MTU considerations are discussed in Section 5.

MTUの考慮事項についてはセクション5で説明します。

2. Conventions and Terminology

2. 表記法と用語

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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

The reader should be familiar with the terms defined in [RFC7665].

リーダーは[RFC7665]で定義されている用語に精通している必要があります。

"SFC Control Element" refers to a logical entity that instructs one or more SFC data plane functional elements on how to process packets within an SFC-enabled domain.

「SFC制御要素」とは、SFC対応ドメイン内のパケットを処理する方法について、1つまたは複数のSFCデータプレーン機能要素に指示する論理エンティティを指す。

3. Subscriber Identifier NSH Variable-Length Context Header

3. 加入者識別子NSH可変長コンテキストヘッダ

Subscriber Identifier is defined as an optional Variable-Length NSH Context Header. Its structure is shown in Figure 1.

加入者識別子は、オプションの可変長NSHコンテキストヘッダとして定義されています。その構造を図1に示します。

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Metadata Class       |      Type     |U|    Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                      Subscriber Identifier                    ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Subscriber Identifier Variable-Length Context Header

図1：加入者識別子可変長コンテキストヘッダ

The fields are described as follows:

フィールドは次のように説明されています。

Metadata Class: MUST be set to 0x0 [RFC8300].

メタデータクラス：0x0 [RFC8300]に設定する必要があります。

Type: 0x00 (see Section 6).

型：0x00（セクション6を参照）。

U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]).

Uビット：未割り当てビット（[RFC8300]のセクション2.5.1を参照）。

Length: Indicates the length of the Subscriber Identifier, in bytes (see Section 2.5.1 of [RFC8300]).

長さ：加入者識別子の長さをバイト単位で示します（[RFC8300]のセクション2.5.1を参照）。

Subscriber Identifier: Carries an opaque local identifier that is assigned to a subscriber by a network operator.

加入者識別子：ネットワーク事業者によって加入者に割り当てられている不透明なローカル識別子を搬送します。

While this document does not specify an internal structure for these identifiers, it also does not provide any cryptographic protection for them; any internal structure to the identifier values chosen will thus be visible on the wire if no secure transport encapsulation is used. Accordingly, in alignment with Section 8.2.2 of [RFC8300], identifier values SHOULD be obfuscated.

この文書はこれらの識別子の内部構造を指定していませんが、それらのための暗号保護も提供しません。したがって、セキュアトランスポートカプセル化が使用されていない場合、選択された識別子値に対する内部構造はワイヤ上に表示されます。したがって、[RFC8300]のセクション8.2.2との整列では、識別値は難読化されるべきです。

The Subscriber Identifier Context Header is used by SFs to enforce per-subscriber policies (e.g., resource quota, customized filtering profile, accounting). To that aim, network operators may rely on identifiers that are generated from those used in legacy deployments (e.g., Section 3.3 of [CASE-MOBILITY]). Alternatively, network operators may use identifiers that are associated with customized policy profiles that are preconfigured on SFs using an out-of-band mechanism. Such a mechanism can be used to rotate the identifiers, thus allowing for better unlinkability (Section 3.2 of [RFC6973]). Such alternative methods may be suboptimal (e.g., scalability issues induced by maintaining and processing finer granular profiles) or inadequate for providing some per-subscriber policies. The assessment of whether a method for defining a subscriber identifier provides the required functionality and whether it is compatible with the capabilities of the SFs at the intended performance level is deployment specific.

加入者識別子コンテキストヘッダは、サブスクライバごとのポリシー（例えば、リソースクォータ、カスタマイズされたフィルタリングプロファイル、アカウンティング）を強制するためにSFSによって使用されます。その目的のために、ネットワーク事業者は、レガシ展開で使用されるものから生成された識別子（例えば、[ケースモビリティ]のセクション3.3）に頼ることができる。あるいは、ネットワーク事業者は、帯域外のメカニズムを使用してSFS上で事前設定されているカスタマイズされたポリシープロファイルに関連付けられている識別子を使用することができる。そのようなメカニズムを使用して識別子を回転させることができ、したがってより優れたリンク許可を可能にする（[RFC6973]のセクション3.2）。そのような代替方法は、加入者ごとのポリシーを提供するために、最適な（例えば、粒状プロファイルを維持および処理することによって誘導されるスケーラビリティの問題）または不適切であり得る。加入者識別子を定義するための方法が必要な機能を提供するかどうか、およびそれが意図されたパフォーマンスレベルでのSFSの機能と互換性があるかどうかの評価は展開固有である。

The classifier and NSH-aware SFs MAY inject a Subscriber Identifier Context Header as a function of a local policy. This local policy should indicate the SFP(s) for which the Subscriber Identifier Context Header will be added. In order to prevent interoperability issues, the type and format of the identifiers to be injected in a Subscriber Identifier Context Header should be configured to nodes authorized to inject and consume such headers. For example, a node can be instructed to insert such data following a type/set scheme (e.g., node X should inject subscriber ID type Y). Other schemes may be envisaged.

分類子およびNSH対応のSFSは、ローカルポリシーの関数として加入者識別子コンテキストヘッダを挿入することができる。このローカルポリシーは、サブスクライバ識別子コンテキストヘッダが追加されるSFPを示す必要があります。相互運用性の問題を防ぐために、加入者識別子コンテキストヘッダに注入される識別子の型とフォーマットは、そのようなヘッダを侵入して消費することを許可されたノードに構成されているべきである。例えば、タイプ/セット方式に従ってそのようなデータを挿入するようにノードを指示することができる（例えば、ノードXは加入者IDタイプYを挿入するべきである）。他の方式が想定されてもよい。

Failures to inject such headers should be logged locally, while a notification alarm may be sent to a Control Element. The details of sending notification alarms (i.e., the parameters affecting the transmission of the notification alarms) might depend on the nature of the information in the Context Header. Parameters for sending alarms, such as frequency, thresholds, and content of the alarm, should be configurable.

そのようなヘッダーを注入するための失敗はローカルに記録され、通知アラームは制御要素に送信されることがあります。通知アラームの送信の詳細（すなわち、通知アラームの送信に影響するパラメータ）は、コンテキストヘッダ内の情報の性質に依存する可能性がある。頻度、しきい値、およびアラームの内容などのアラームを送信するためのパラメータは、設定可能である必要があります。

The default behavior of intermediary NSH-aware nodes is to preserve Subscriber Identifier Context Headers (i.e., the information can be passed to next-hop NSH-aware nodes), but local policy may require an intermediary NSH-aware node to strip a Subscriber Identifier Context Header after processing it.

中間性NSH対応ノードのデフォルトの動作は、サブスクライバ識別子コンテキストヘッダを保持することです（つまり、情報をネクストホップNSH対応ノードに渡すことができます）が、ローカルポリシーでは中間のNSH対応ノードがサブスクライバ識別子を削除する必要がある場合があります。処理後のコンテキストヘッダ。

NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber identifiers.

NSH対応のSFSは、未知の加入者識別子を運ぶコンテキストヘッダを無視する必要があります。

Local policies at NSH-aware SFs may require running additional validation checks on the content of these Context Headers (e.g., accepting only some lengths or types). These policies may also indicate the behavior to be followed by an NSH-aware SF if the validation checks fail (e.g., removing the Context Header from the packet). These additional validation checks are deployment specific. If validation checks fail on a Subscriber Identifier Context Header, an NSH-aware SF MUST ignore that Context Header. The event should be logged locally, while a notification alarm may be sent to a Control Element if the NSH-aware SF is instructed to do so. For example, an SF will discard Subscriber Identifier Context Headers conveying identifiers in all formats that are different from the one the SF is instructed to expect.

NSH対応のSFSのローカルポリシーは、これらのコンテキストヘッダのコンテンツに対して追加の検証チェックを実行する必要がある場合があります（例えば、ある長さや型だけを受け入れます）。これらのポリシーは、検証チェックが失敗した場合（例えば、パケットからコンテキストヘッダの削除）の場合に、その後にNSH対応のSFが続くような動作を示してもよい。これらの追加の検証チェックは展開固有です。加入者識別子コンテキストヘッダで検証チェックが失敗した場合、NSH対応SFはそのコンテキストヘッダを無視する必要があります。NSH対応SFがそうするように指示された場合、そのイベントはローカルに記録され、通知アラームは制御要素に送信されます。たとえば、SFは、SFが期待されるように指示されたものとは異なるすべてのフォーマットで識別子を伝達するサブスクライバ識別子コンテキストヘッダーを破棄します。

Multiple Subscriber Identifier Context Headers MAY be present in the NSH, each carrying a distinct opaque value but all pointing to the same subscriber. This may be required, e.g., by policy enforcement mechanisms in a mobile network where some SFs rely on IP addresses as subscriber identifiers, while others use non-IP-specific identifiers such as those listed in [RFC8371] and Section 3.3.2 of [CASE-MOBILITY]. When multiple Subscriber Identifier Context Headers are present and an SF is instructed to strip the Subscriber Identifier Context Header, that SF MUST remove all Subscriber Identifier Context Headers.

複数の加入者識別子コンテキストヘッダがNSHに存在し、それぞれが異なる不透明値を搬送するが、すべて同じ加入者を指している。これは、例えば、一部のSFSが加入者識別子としてIPアドレスに依存しているモバイルネットワーク内のポリシー執行メカニズムによって必要とされるかもしれませんが、他のものは[RFC8371]および[RFC8371]とセクション3.3.2のもののような非IP固有の識別子を使用する必要があります。ケースモビリティ]。複数の加入者識別子コンテキストヘッダが存在し、SFがサブスクライバ識別子コンテキストヘッダを削除するように指示され、そのSFはすべての加入者識別子コンテキストヘッダを削除する必要があります。

4. Performance Policy Identifier NSH Variable-Length Context Headers

4. パフォーマンスポリシー識別子NSH可変長コンテキストヘッダ

Dedicated service-specific performance identifiers are defined to differentiate between services that require specific treatment in order to exhibit a performance characterized by, e.g., ultra-low latency (ULL) or ultra-high reliability (UHR). Other policies can be considered when instantiating a Service Function Chain within an SFC-enabled domain. They are conveyed in the Performance Policy Identifier Context Header.

専用のサービス固有の性能識別子は、例えば超低遅延（ULL）または超高信頼性（UHR）によって特徴付けられる性能を示すために特定の治療を必要とするサービスを区別するために定義される。SFC対応ドメイン内でサービス機能チェーンをインスタンス化するときに他のポリシーを考慮することができます。それらはパフォーマンスポリシー識別子コンテキストヘッダで伝達されます。

The Performance Policy Identifier Context Header is inserted in an NSH packet so that downstream NSH-aware nodes can make use of the performance information for proper selection of suitably distributed SFC paths, SF instances, or applicable policy at SFs. Note that the use of the performance policy identifier is not helpful if the path computation is centralized and a strict SFP is presented as local policy to SF Forwarders (SFFs).

パフォーマンスポリシー識別子コンテキストヘッダは、ダウンストリームNSH対応ノードが、適切に分散されたSFCパス、SFインスタンス、またはSFSで適用可能なポリシーの適切な選択のためにパフォーマンス情報を利用することができるように、NSHパケットに挿入されます。PATHER POLICY IDの使用は、パス計算が集中化され、厳密なSFPがSF Forwarders（SFF）にローカルポリシーとして表示されます。

The Performance Policy Identifier Context Header allows for the distributed enforcement of a per-service policy such as requiring an SFP to only include specific SF instances (e.g., SFs located within the same Data Center (DC) or those that are exposing the shortest delay from an SFF). Details of this process are implementation specific. For illustration purposes, an SFF may retrieve the details of usable SFs based upon the corresponding performance policy identifier. Typical criteria for instantiating specific SFs include location, performance, or proximity considerations. For the particular case of UHR services, the standby operation of backup capacity or the presence of SFs deployed in multiple instances may be requested.

Performance Policy Identifier Contextヘッダーは、SFPが特定のSFインスタンス（たとえば、同じデータセンター内にあるSFS）、またはから最短遅延を露出しているSFSのみを含むなど、サービスごとのポリシーの分散型適用を可能にします。SFF）。このプロセスの詳細は実装固有です。説明のために、SFFは対応する性能ポリシー識別子に基づいて使用可能なSFSの詳細を検索することができる。特定のSFSをインスタンス化するための典型的な基準には、場所、性能、または近接性の考慮事項が含まれます。UHRサービスの特定のケースの場合、バックアップ容量のスタンバイ動作または複数のインスタンスでデプロイされているSFSの存在が要求されてもよい。

In an environment characterized by frequent changes of link and path behavior (for example, due to variable load or availability caused by propagation conditions on a wireless link), the SFP may have to be adapted dynamically by on-the-move SFC path and SF instance selection.

リンクおよびパスの動作の頻繁な変更を特徴とする環境で（例えば、無線リンク上の伝播条件によって引き起こされる可変負荷または可用性のために）、SFPは移動SFCパスとSFによって動的に調整されなければならないかもしれません。インスタンスの選択

Performance Policy Identifier is defined as an optional Variable-Length Context Header. Its structure is shown in Figure 2.

パフォーマンスポリシーIDは、オプションの可変長コンテキストヘッダーとして定義されています。その構造を図2に示します。

The default behavior of intermediary NSH-aware nodes is to preserve such Context Headers (i.e., the information can be passed to next-hop NSH-aware nodes), but local policy may require an intermediary NSH-aware node to strip one Context Header after processing it.

中間NSH対応ノードのデフォルトの動作は、そのようなコンテキストヘッダーを保持することです（つまり、情報をNext-Hop NSH対応ノードに渡すことができます）が、ローカルポリシーでは中間のNSH対応ノードが1つのコンテキストヘッダーを削除する必要がある場合があります。処理してください。

Multiple Performance Policy Identifier Context Headers MAY be present in the NSH, each carrying an opaque value for a distinct policy that needs to be enforced for a flow. Supplying conflicting policies may complicate the SFP computation and SF instance location. Corresponding rules to detect conflicting policies may be provided as a local policy to the NSH-aware nodes. When such conflict is detected by an NSH-aware node, the default behavior of the node is to discard the packet and send a notification alarm to a Control Element.

複数の性能ポリシー識別子コンテキストヘッダがNSHに存在する可能性があり、それぞれがフローに対して強制される必要がある異なるポリシーの不透明な値を伝送します。競合するポリシーを供給すると、SFP計算とSFインスタンスの場所が複雑になる可能性があります。矛盾するポリシーを検出するための対応する規則は、NSH対応ノードに対するローカルポリシーとして提供されてもよい。このような競合がNSH対応ノードによって検出されると、ノードのデフォルトの動作はパケットを破棄し、通知アラームを制御要素に送信することです。

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Metadata Class       |      Type     |U|    Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     Performance Policy Identifier             ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Performance Policy Identifier Variable-Length Context Header

図2：パフォーマンスポリシー識別子可変長コンテキストヘッダ

The fields are described as follows:

フィールドは次のように説明されています。

Metadata Class: MUST be set to 0x0 [RFC8300].

メタデータクラス：0x0 [RFC8300]に設定する必要があります。

Type: 0x01 (see Section 6).

タイプ：0x01（セクション6を参照）。

U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]).

Uビット：未割り当てビット（[RFC8300]のセクション2.5.1を参照）。

Length: Indicates the length of the Performance Policy Identifier, in bytes (see Section 2.5.1 of [RFC8300]).

長さ：パフォーマンスポリシー識別子の長さをバイト単位で示します（[RFC8300]のセクション2.5.1を参照）。

Performance Policy Identifier: Represents an opaque value pointing to a specific performance policy to be enforced. The structure and semantics of this field are deployment specific.

パフォーマンスポリシーID：特定のパフォーマンスポリシーを指す不透明な値を表します。このフィールドの構造と意味は展開固有です。

5. MTU Considerations

5. MTUの考慮事項

As discussed in Section 5.6 of [RFC7665], the SFC architecture prescribes that additional information be added to packets to:

[RFC7665]のセクション5.6で説明されているように、SFCアーキテクチャは、追加情報がパケットに追加されることを規定しています。

* Identify SFPs. This is typically the NSH Base Header (Section 2.2 of [RFC8300]) and Service Path Header (Section 2.3 of [RFC8300]).

* SFPを識別します。これは通常NSHベースヘッダー（[RFC8300]のセクション2.2）とサービスパスヘッダー（[RFC8300]のセクション2.3）です。

* Carry metadata such those defined in Sections 3 and 4.

* セクション3と4で定義されているメタデータをキャリアします。

* Steer the traffic along the SFPs: This is realized by means of transport encapsulation.

* SFPに沿ってトラフィックを操縦します。これはトランスポートカプセル化によって実現されます。

This added information increases the size of the packet to be carried along an SFP.

この追加された情報は、SFPに沿って運ばれるパケットのサイズを増加させる。

Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network operators to increase the underlying MTU so that NSH traffic is forwarded within an SFC-enabled domain without fragmentation. The available underlying MTU should be taken into account by network operators when providing SFs with the required Context Headers to be injected per SFP and the size of the data to be carried in these Context Headers.

[RFC8300]のセクション5と整列されているため、NSHトラフィックが断片化なしでSFC対応ドメイン内で転送されるように、ネットワークオペレータに基礎となるMTUを増やすことをお勧めします。利用可能な基礎となるMTUは、SFPごとにSFSを提供するSFSとこれらのコンテキストヘッダーで搬送されるデータのサイズを提供する場合にネットワーク事業者によって考慮されるべきです。

If the underlying MTU cannot be increased to accommodate the NSH overhead, network operators may rely upon a transport encapsulation protocol with the required fragmentation handling. The impact of activating such feature on SFFs should be carefully assessed by network operators (Section 5.6 of [RFC7665]).

NSHオーバーヘッドに対応するために基礎となるMTUを増やすことができない場合、ネットワーク事業者は必要な断片化処理を用いてトランスポートカプセル化プロトコルに頼ることがある。SFFSに対するそのような機能を起動することの影響は、ネットワーク事業者によって慎重に評価されるべきです（[RFC7665]のセクション5.6）。

When dealing with MTU issues, network operators should consider the limitations of various transport encapsulations such as those discussed in [INTAREA-TUNNELS].

MTUの問題を扱う場合、ネットワーク事業者は[Intarea-Tunnels]で説明されているもののようなさまざまなトランスポートカプセル化の制限を考慮する必要があります。

6. IANA Considerations

6. IANAの考慮事項

IANA has assigned the following types from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" subregistry (0x0000 IETF Base NSH MD Class) available at: <https://www.iana.org/assignments/ nsh>.

IANAには、「NSH IETF-割り当て済みオプション可変長メタデータ型」（https://www.iana.org/assignments/ nsh>から、 "NSH IETFが割り当てられたオプションの可変長メタデータ型"サブレジスト（0x0000 IETFベースNSH MDクラス）から次のタイプが割り当てられています。

           +=======+===============================+===========+
           | Value | Description                   | Reference |
           +=======+===============================+===========+
           | 0x00  | Subscriber Identifier         | [RFC8979] |
           +-------+-------------------------------+-----------+
           | 0x01  | Performance Policy Identifier | [RFC8979] |
           +-------+-------------------------------+-----------+

Table 1: NSH IETF-Assigned Optional Variable-Length Metadata Types Additions

表1：NSH IETFが割り当てられたオプションの可変長メタデータ型追加

7. Security Considerations

7. セキュリティに関する考慮事項

Data plane SFC-related security considerations, including privacy, are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. In particular, Section 8.2.2 of [RFC8300] states that attached metadata (i.e., Context Headers) should be limited to that necessary for correct operation of the SFP. Section 8.2.2 of [RFC8300] indicates that metadata considerations that operators can take into account when using NSH are discussed in [RFC8165].

プライバシーを含むデータプレーンのSFC関連のセキュリティ上の考慮事項については、[RFC7665]のセクション6と[RFC8300]のセクション8で説明します。特に、[RFC8300]のセクション8.2.2は、接続されたメタデータ（すなわちコンテキストヘッダ）がSFPの正しい動作に必要なものに限定されるべきであると述べている。[RFC8300]のセクション8.2.2は、NSHを使用するときにオペレータが考慮に入れることができるメタデータに関する考慮事項を[RFC8165]で説明していることを示します。

As specified in [RFC8300], means to prevent leaking privacy-related information outside an SFC-enabled domain are natively supported by the NSH given that the last SFF of an SFP will systematically remove the NSH (and therefore the identifiers defined in this specification) before forwarding a packet exiting the SFP.

[RFC8300]で指定されているように、SFC対応ドメイン外のプライバシー関連情報の漏洩を防ぐための手段は、SFPの最後のSFFがNSHを系統的に削除した場合（したがって本明細書で定義されている識別子）を使用しています（したがって）NSHによってネイティブにサポートされています。SFPを終了するパケットを転送する前に。

Nodes that are involved in an SFC-enabled domain are assumed to be trusted (Section 1.1 of [RFC8300]). Discussion of means to check that only authorized nodes are traversed when a packet is crossing an SFC-enabled domain is out of scope of this document.

SFC対応ドメインに関与しているノードは信頼されると想定されています（[RFC8300]のセクション1.1）。パケットがSFC対応ドメインを渡っているときに許可されたノードのみがトラバースされることを確認するための手段の説明は、このドキュメントの範囲外です。

Both Subscriber Identifier and Performance Policy Identifier Context Headers carry opaque data. In particular, the Subscriber Identifier Context Header is locally assigned by a network provider and can be generated from some of the information that is already conveyed in the original packets from a host (e.g., internal IP address) or other information that is collected from various sources within an SFC-enabled domain (e.g., line identifier). The structure of the identifiers conveyed in these Context Headers is communicated only to entitled NSH-aware nodes. Nevertheless, some structures may be easily inferred from the headers if trivial structures are used (e.g., IP addresses). As persistent identifiers facilitate tracking over time, the use of indirect and non-persistent identification is thus RECOMMENDED.

加入者識別子とパフォーマンスポリシー識別子コンテキストヘッダの両方が不透明なデータを運ぶ。特に、加入者識別子コンテキストヘッダはネットワークプロバイダによってローカルに割り当てられ、すでにホスト（例えば内部IPアドレス）またはさまざまなものから収集される他の情報からすでに元のパケット内で既に伝達されている情報のいくつかから生成され得る。SFC対応ドメイン内のソース（Line Identifier）。これらのコンテキストヘッダで伝達されている識別子の構造は、NSH対応ノードの権利のみに通信されます。それにもかかわらず、些細な構造が使用されている場合（例えば、IPアドレス）の場合、いくつかの構造はヘッダから容易に推測され得る。持続的な識別子が経時的に追跡を容易にするにつれて、間接的および非永続的な識別の使用は推奨される。

Moreover, the presence of multiple Subscriber Identifier Context Headers in the same NSH allows a misbehaving node from within the SFC-enabled domain to bind these identifiers to the same subscriber. This can be used to track that subscriber more effectively. The use of non-persistent (e.g., regularly randomized) identifiers as well as the removal of the Subscriber Identifier Context Headers from the NSH by the last SF making use of such headers soften this issue (see "data minimization" discussed in Section 3 of [RFC8165]). Such behavior is especially strongly recommended in case no encryption is enabled.

さらに、同じNSH内の複数の加入者識別子コンテキストヘッダの存在は、SFC対応ドメイン内からの不正なノードがこれらの識別子を同じ加入者にバインドすることを可能にする。これは、その加入者をより効果的に追跡するために使用できます。非永続（例えば、定期的にランダム化された）識別子の使用、ならびにNSHからの加入者識別子のコンテキストヘッダの使用は、この問題を解決する（セクション3で説明した「データ最小化」を参照されたい）。[RFC8165]）。暗号化が有効になっていない場合、そのような動作は特に強く推奨されます。

A misbehaving node from within the SFC-enabled domain may alter the content of Subscriber Identifier and Performance Policy Identifier Context Headers, which may lead to service disruption. Such an attack is not unique to the Context Headers defined in this document; measures discussed in Section 8 of [RFC8300] are to be followed. A mechanism for NSH integrity is specified in [NSH-INTEGRITY].

SFC対応ドメイン内からの不正なノードは、サブスクライバ識別子およびパフォーマンスポリシー識別子コンテキストヘッダの内容を変更することができ、これはサービスの中断につながる可能性がある。そのような攻撃は、この文書で定義されているコンテキストヘッダーに固有のものではありません。[RFC8300]の第8章で説明した対策に従うべきです。NSH整合性のメカニズムは[NSH-Integrity]で指定されています。

If no secure transport encapsulation is enabled, the use of trivial subscriber identifier structures, together with the presence of specific SFs in a Service Function Chain, may reveal sensitive information to every on-path device. Also, operational staff in teams managing these devices could gain access to such user privacy-affecting data. Such disclosure can be a violation of legal requirements because such information should be available to very few network operator personnel. Furthermore, access to subscriber data usually requires specific access privilege levels. To maintain that protection, an SF keeping operational logs should not log the content of Subscriber and Performance Policy Identifier Context Headers unless the SF actually uses the content of these headers for its operation. As discussed in Section 8.2.2 of [RFC8300], subscriber-identifying information should be obfuscated, and, if an operator deems cryptographic integrity protection is needed, security features in the transport encapsulation protocol (such as IPsec) must be used. A mechanism for encrypting sensitive NSH data is specified in [NSH-INTEGRITY]. This mechanism can be considered by network operators when enhanced SF-to-SF security protection of NSH metadata is required (e.g., to protect against compromised SFFs).

安全なトランスポートカプセル化が有効になっていない場合は、サービス機能チェーン内の特定のSFSの存在とともに、簡単なサブスクライバ識別子構造の使用は、すべてのONパスデバイスに機密情報を明らかにする可能性があります。また、これらのデバイスを管理するチームの運用スタッフは、そのようなユーザーのプライバシーに影響を与える可能性があります。そのような開示は、そのような情報が非常に少ないネットワークオペレータ担当者に利用可能であるべきであるため、法的要件の違反とすることができる。さらに、加入者データへのアクセスは通常、特定のアクセス権限を必要とします。その保護を維持するために、SFの操作ログを保持していると、SFが実際にその操作のためにこれらのヘッダーのコンテンツを使用しない限り、サブスクライバとパフォーマンスポリシー識別子のコンテキストヘッダーの内容を記録しないでください。 [RFC8300]のセクション8.2.2で説明されているように、加入者識別情報は難読化されるべきであり、オペレータが暗号化された整合性保護を必要とする場合は、トランスポートカプセル化プロトコル（IPsecなど）のセキュリティ機能を使用する必要があります。敏感なNSHデータを暗号化するためのメカニズムは[NSH-Integrity]で指定されています。このメカニズムは、NSHメタデータのSFからSFセキュリティ保護を強化する必要がある場合（例えば、侵入先SFFから保護するために）ネットワーク事業者によって考慮することができる。

Some events are logged locally with notification alerts sent by NSH-aware nodes to a Control Element. These events SHOULD be rate limited.

いくつかのイベントは、NSH対応ノードによって制御要素に送信された通知アラートでローカルに記録されます。これらのイベントはレート制限されるべきです。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[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。「サービス機能連鎖（SFC）アーキテクチャ」、RFC 7665、DOI 10.17487 / RFC7665、<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>。

[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。、およびC. Pignataro、Ed。、「ネットワークサービスヘッダ（NSH）」、RFC 8300、DOI 10.17487 / RFC8300、2018年1月、<https：//www.rfc-editor.org/info/rfc8300>。

8.2. Informative References

8.2. 参考引用

[CASE-MOBILITY] Haeffner, W., Napper, J., Stiemerling, M., Lopez, D. R., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", Work in Progress, Internet-Draft, draft-ietf-sfc-use-case-mobility-09, 1 January 2019, <https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09>.

[ケースモビリティ] Haeffner、W.、Napper、J.、Stiemerling、M.、Lopez、Dr、J.Uttaro、「モバイルネットワークにおけるサービス機能連鎖ユースケース」、進行中の作業、インターネットドラフト、ドラフト - 2019年1月1日、<https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09>。

[INTAREA-TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, Internet-Draft, draft-ietf-intarea-tunnels-10, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10>.

[Intarea-Tunnels] Touch、J.およびM. Townsley、「インターネットアーキテクチャのIPトンネル」、進行中の作業、インターネットドラフト、Draft-IETF-Intarea-Tunnels-10,12,12、<https：//tools.ietf.org/html/draft-ietf-intarea-tunnels-10>>。

[NSH-INTEGRITY] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers", Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-03, 22 January 2021, <https://tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-03>.

[NSH-Integrity] Boucadair、M.、Reddy.k、T.、D.ウィング、「ネットワークサービスヘッダのための整合性保護（NSH）および敏感なコンテキストヘッダの暗号化、進行中、インターネットドラフト、ドラフト-ietf-sfc-nsh-integrity-03,2021、<https：//tools.ietf.org/html/draft-ietf-sfc-nsh-integrity-03>

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。

[RFC8165] Hardie, T., "Design Considerations for Metadata Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, <https://www.rfc-editor.org/info/rfc8165>.

[RFC8165] hardie、T.、「メタデータ挿入の設計上の考慮事項」、RFC 8165、DOI 10.17487 / RFC8165、2017年5月、<https：//www.rfc-editor.org/info/rfc8165>。

[RFC8371] Perkins, C. and V. Devarapalli, "Mobile Node Identifier Types for MIPv6", RFC 8371, DOI 10.17487/RFC8371, July 2018, <https://www.rfc-editor.org/info/rfc8371>.

[RFC8371] Perkins、C、V.Devarapalli、「MIPv6のモバイルノード識別子型」、RFC 8371、DOI 10.17487 / RFC8371、2018年7月、<https：//www.rfc-editor.org/info/rfc8371>。

[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 16", Version 16.5.0, TS 23.401, December 2019.

[TS23401] 3GPP、「一般的なパケット無線サービス（GPRS）は、進化した普遍的な地上無線アクセスネットワーク（E-UTRAN）アクセス、リリース16 "、バージョン16.5.0、TS 23.401、2019年12月に強化されました。

[TS23501] 3GPP, "System architecture for the 5G System (5GS), Release 16", Version 16.3.0, TS 23.501, December 2019.

[TS23501] 3GPP、「5Gシステム（5GS）のシステムアーキテクチャ、リリース16」、バージョン16.3.0、TS 23.501、2019年12月。

Acknowledgements

謝辞

Comments from Joel Halpern on a previous draft version and from Carlos Bernardos are appreciated.

以前のドラフト版とCarlos BernardosからのJoel Halpernからのコメントが高く評価されています。

Contributions and review by Christian Jacquenet, Danny Lachos, Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose, Donald Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky are thankfully acknowledged.

Christian Jacquenet、Danny Lachos、Dibashish Purkayastha、Christian Esteve Rothenberg、Kyle Larse、Donald Eastlake、Qin Wu、Shunsuke Mirske、およびGreg MirskyというChristian Esteve Rotherg、Kyld Eastleake、Kyld Eastleake、Qin Wu、Qin Wu、Greg Mirskyがありがとうございました。

Many thanks to Robert Sparks for the secdir review.

Secdirレビューのためにロバートがスパークしてくれてありがとう。

Thanks to Barry Leiba, Erik Kline, Éric Vyncke, Robert Wilton, and Magnus Westerlund for the IESG review.

Barry Leiba、Erik Kline、Erk Vyncke、Robert Wilton、およびMagnus WesterlundのおかげでIESGレビュー。

Special thanks to Benjamin Kaduk for the careful review and suggestions that enhanced this specification.

この仕様を強化する慎重なレビューと提案のためのBenjamin Kadukに感謝します。

Authors' Addresses

著者の住所

Behcet Sarikaya

SARIKAYA BEHCET

   Email: sarikaya@ieee.org

Dirk von Hugo Deutsche Telekom Deutsche-Telekom-Allee 9 D-64295 Darmstadt Germany

Dirk Von Hugo Deutsche Telekom Deutsche-Telekom-Allee 9 D-64295 Darmstadtドイツ

   Email: Dirk.von-Hugo@telekom.de

Mohamed Boucadair Orange 3500 Rennes France

Mohamed Boucadair Orange 3500 Rennesフランス

   Email: mohamed.boucadair@orange.com