[要約] 要約： RFC 7149は、サービスプロバイダ環境からのソフトウェア定義ネットワーキング（SDN）の視点を提供しています。目的： このRFCの目的は、サービスプロバイダがSDNを実装する際の課題や利点を理解し、効果的なネットワーク管理を実現するためのガイダンスを提供することです。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7149 C. Jacquenet
Category: Informational France Telecom
ISSN: 2070-1721 March 2014
Software-Defined Networking: A Perspective from within a Service Provider Environment
ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの視点
Abstract
概要
Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.
Software-Defined Networking（SDN）は、過去数年間、ネットワーク業界の主要な話題の1つでした。それでも、SDNが実際にカバーするものの明確な定義は、これまで広く認められていません。このドキュメントは、サービスプロバイダー環境内から見た、SDNに関する要件、問題、およびその他の考慮事項についての視点を提供することにより、SDNランドスケープを明確にすることを目的としています。
It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.
これは、SDNの真の意味を無限に議論することを意味するのではなく、SDNの傘下で使用できる手法の機能分類法を提案し、そのような手法を組み合わせてアクティブ化すると必然的に生じるさまざまな保留中の問題について詳しく説明します。そのため、SDNの定義は、明確化のためにのみ言及されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7149.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7149で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Introducing Software-Defined Networking .........................4
2.1. A Tautology? ...............................................4
2.2. On Flexibility .............................................4
2.3. A Tentative Definition .....................................5
2.4. Functional Metadomains .....................................6
3. Reality Check ...................................................6
3.1. Remember the Past ..........................................7
3.2. Be Pragmatic ...............................................8
3.3. Measure Experience against Expectations ....................8
3.4. Design Carefully ...........................................9
3.5. On OpenFlow ................................................9
3.6. Non-goals .................................................10
4. Discussion .....................................................11
4.1. Implications of Full Automation ...........................11
4.2. Bootstrapping an SDN ......................................12
4.3. Operating an SDN ..........................................14
4.4. The Intelligence Resides in the PDP .......................15
4.5. Simplicity and Adaptability vs. Complexity ................16
4.6. Performance and Scalability ...............................16
4.7. Risk Assessment ...........................................17
5. Security Considerations ........................................17
6. Acknowledgements ...............................................18
7. Informative References .........................................18
The Internet has become the federative network that supports a wide range of service offerings. The delivery of network services such as IP VPNs assumes the combined activation of various capabilities that include (but are not necessarily limited to) forwarding and routing (e.g., customer-specific addressing scheme management, dynamic path computation to reach a set of destination prefixes, dynamic establishment of tunnels, etc.); Quality of Service (e.g., traffic classification, marking, conditioning, and scheduling); security (e.g., filters to protect customer premises from network-originated attacks, to avoid malformed route announcements, etc.); and management (e.g., fault detection and processing).
インターネットは、幅広いサービスをサポートする連合ネットワークになりました。 IP VPNなどのネットワークサービスの配信は、転送とルーティング（たとえば、顧客固有のアドレス指定スキーム管理、一連の宛先プレフィックスに到達するための動的パス計算）を含む（ただし、必ずしもこれらに限定されない）さまざまな機能の組み合わせのアクティブ化を前提としています。トンネルの動的確立など）;サービス品質（トラフィックの分類、マーキング、条件付け、スケジューリングなど）セキュリティ（例：不正なルートアナウンスを回避するために、ネットワークに起因する攻撃から顧客の敷地を保護するためのフィルターなど）。および管理（例：障害の検出と処理）。
As these services not only grow in variety but also in complexity, their design, delivery, and operation have become a complex alchemy that often requires various levels of expertise. This situation is further aggravated by the wide variety of (network) protocols and tools, as well as recent convergence trends driven by Any Time, Any Where, Any Device (ATAWAD); ATAWADs are meant to make sure that an end user can access the whole range of services he/she has subscribed to whatever the access and device technologies, wherever the end user is connected to the network, and whether or not this end user is in motion.
これらのサービスは多様性だけでなく複雑さも増すため、その設計、配信、および運用は、さまざまなレベルの専門知識を必要とする複雑な錬金術になっています。この状況は、多種多様な（ネットワーク）プロトコルとツール、およびいつでも、どこでも、すべてのデバイス（ATAWAD）によって引き起こされる最近の収束傾向によってさらに悪化します。 ATAWADは、エンドユーザーがネットワークに接続されている場所、およびこのエンドユーザーが動いているかどうかに関係なく、エンドユーザーがアクセスおよびデバイステクノロジーに加入しているサービスの全範囲にアクセスできることを確認するためのものです。
Yet, most of these services have been deployed for the past decade, primarily based upon often static service production procedures that are more and more exposed to the risk of erroneous configuration commands. In addition, most of these services do not assume any specific negotiation between the customer and the service provider or between service providers, besides the typical financial terms.
しかし、これらのサービスのほとんどは過去10年間展開されており、主に、誤った構成コマンドのリスクにさらされることが多い静的なサービスプロダクション手順に基づいています。さらに、これらのサービスのほとんどは、一般的な金銭的条件以外に、顧客とサービスプロバイダー間またはサービスプロバイダー間の特定の交渉を想定していません。
At best, five-year master plans are referred to as the network planning policy that will be enforced by the service provider given the foreseen business development perspectives, manually computed traffic forecasts, and market coverage (fixed/mobile and residential/ corporate). This so-called network planning policy may very well affect the way resources are allocated in a network, but it clearly fails to be adequately responsive to highly dynamic customer requirements in an "always-on" fashion. The need for improved service delivery procedures (including the time it takes to deliver the service once the possible negotiation phase is completed) is even more critical for corporate customers.
せいぜい5年間のマスタープランは、予測されるビジネス開発の見通し、手動で計算されたトラフィック予測、および市場範囲（固定/モバイルおよび住宅/企業）を考慮してサービスプロバイダーによって適用されるネットワーク計画ポリシーと呼ばれます。このいわゆるネットワーク計画ポリシーは、リソースがネットワークに割り当てられる方法に非常によく影響する可能性がありますが、「常にオン」の方法で非常に動的な顧客要件に適切に対応できないことは明らかです。改善されたサービス提供手順の必要性（可能な交渉フェーズが完了してからサービスを提供するのにかかる時間を含む）は、企業顧客にとってさらに重要です。
In addition, various tools are used for different, sometimes service-centric, management purposes, but their usage is not necessarily coordinated for event aggregation, correlation, and processing. This lack of coordination may come at the cost of extra complexity and possible customer Quality-of-Experience degradation.
さらに、さまざまな、場合によってはサービス中心の管理目的でさまざまなツールが使用されますが、それらの使用法は、イベントの集約、相関、および処理のために必ずしも調整されていません。この調整の欠如は、余分な複雑さと潜在的な顧客体験品質の低下という犠牲を払うことになるかもしれません。
Multi-service, multi-protocol, multi-technology-convergent, and dynamically adaptive networking environments of the near future have therefore become one of the major challenges faced by service providers.
したがって、近い将来のマルチサービス、マルチプロトコル、マルチテクノロジーの収束、動的適応型ネットワーク環境は、サービスプロバイダーが直面する主要な課題の1つになっています。
This document aims to clarify the SDN landscape by providing a perspective on the functional taxonomy of the techniques that can be used in SDN, as seen from within a service provider environment.
このドキュメントは、サービスプロバイダー環境内から見た、SDNで使用できる手法の機能分類法に関する視点を提供することにより、SDNランドスケープを明確にすることを目的としています。
The separation of the forwarding and control planes (beyond implementation considerations) has almost become a gimmick to promote flexibility as a key feature of the SDN approach. Technically, most of the current router implementations have been assuming this separation for decades. Routing processes (such as IGP and BGP route computation) have often been software based, while forwarding capabilities are usually implemented in hardware.
フォワーディングプレーンとコントロールプレーンの分離（実装に関する考慮事項を超える）は、SDNアプローチの主要な機能としての柔軟性を促進するためのギミックになりつつあります。技術的には、現在のルーター実装のほとんどは、何十年もの間この分離を想定しています。ルーティングプロセス（IGPおよびBGPルート計算など）は、多くの場合ソフトウェアベースでしたが、転送機能は通常ハードウェアで実装されています。
As such, at the time of writing, what is considered to be state of the art tends to confirm the said separation, which rather falls under a tautology.
このように、執筆の時点で、最先端と見なされるものは、上記の分離を確認する傾向があり、むしろトートロジーに該当します。
But, a somewhat centralized, "controller-embedded", control plane for the sake of optimized route computation before the Forwarding Information Base (FIB) population is certainly another story.
しかし、Forwarding Information Base（FIB）ポピュレーションが別の話になる前に、ルート計算を最適化するために、やや集中化された「コントローラ組み込み」のコントロールプレーンを使用します。
Promoters of SDN have argued that it provides additional flexibility in how the network is operated. This is undoubtedly one of the key objectives that must be achieved by service providers. This is because the ability to dynamically adapt to a wide range of customer requests for flexible network service delivery is an important competitive advantage. But, flexibility is much, much more than separating the control and forwarding planes to facilitate forwarding decision-making processes.
SDNのプロモーターは、ネットワークの運用方法に追加の柔軟性を提供すると主張しています。これは間違いなく、サービスプロバイダーが達成する必要がある主要な目的の1つです。これは、柔軟なネットワークサービス配信に対する幅広い顧客の要求に動的に適応できることが、競争上の重要な利点であるためです。しかし、柔軟性は、制御プレーンと転送プレーンを分離して転送の意思決定プロセスを容易にすることよりもはるかに優れています。
For example, the ability to accommodate short duration extra bandwidth requirements so that end users can stream a video file to their 4G terminal device is an example of the flexibility that several mobile operators are currently investigating.
たとえば、エンドユーザーが4G端末デバイスにビデオファイルをストリーミングできるように、短時間の追加帯域幅要件に対応する機能は、いくつかのモバイルオペレーターが現在調査している柔軟性の例です。
From this perspective, the ability to predict the network behavior as a function of the network services to be delivered is of paramount importance for service providers, so that they can assess the impact of introducing new services or activating additional network features or enforcing a given set of (new) policies from both financial and technical standpoints. This argues in favor of investigating advanced network emulation engines, which can be fed with information that can be derived from [LS-DISTRIB], for example.
この観点から、提供されるネットワークサービスの機能としてネットワークの動作を予測する機能は、サービスプロバイダーにとって最も重要であり、新しいサービスの導入、追加のネットワーク機能のアクティブ化、または特定のセットの適用の影響を評価できます。財務的および技術的両方の観点からの（新しい）政策の。これは、たとえば、[LS-DISTRIB]から導出できる情報を提供できる高度なネットワークエミュレーションエンジンの調査を支持して主張しています。
Given the rather broad scope that the term "flexibility" suggests:
「柔軟性」という用語が示唆するかなり広い範囲を考えると、
o Current SDN-labeled solutions are claimed to be flexible, although the notion is hardly defined. The exact characterization of what flexibility actually means is yet to be provided. Further work needs, therefore, to be conducted so that flexibility can be precisely defined in light of various criteria such as network evolution capabilities as a function of the complexity introduced by the integration of SDN techniques and seamless capabilities (i.e., the ability to progressively introduce SDN-enabled devices without disrupting network and service operation, etc.).
o 現在のSDNラベルの付いたソリューションは柔軟であると主張されていますが、その概念はほとんど定義されていません。柔軟性が実際に何を意味するかについての正確な特性はまだ提供されていません。したがって、SDN技術とシームレスな機能の統合によって導入される複雑さの関数としてのネットワーク進化機能（つまり、段階的に導入する機能）の関数として、ネットワーク進化機能などのさまざまな基準に照らして柔軟性を正確に定義できるように、さらに作業が必要になります。ネットワークやサービスの運用を中断することのないSDN対応デバイスなど）。
o The exposure of programmable interfaces is not a goal per se; rather, it is a means to facilitate configuration procedures for improved flexibility.
o プログラマブルインターフェイスの公開は、それ自体が目標ではありません。むしろ、柔軟性を高めるための構成手順を容易にする手段です。
We define Software-Defined Networking as the set of techniques used to facilitate the design, delivery, and operation of network services in a deterministic, dynamic, and scalable manner. The said determinism refers to the ability to completely master the various components of the service delivery chain, so that the service that has been delivered complies with what has been negotiated and contractually defined with the customer.
ソフトウェア定義ネットワーキングは、ネットワークサービスの設計、配信、および運用を、決定論的、動的、およびスケーラブルな方法で促進するために使用される一連の手法として定義されています。上記の決定論は、サービス提供チェーンのさまざまなコンポーネントを完全に習得して、提供されたサービスが、顧客と交渉して契約で定義した内容に準拠する能力を指します。
As such, determinism implies that the ability to control how network services are structured, designed, and delivered and where traffic should be forwarded in the network is for optimized resource usage. Although not explicitly restated in the following sections of the document, determinism lies beneath any action that may be taken by a service provider once service parameter negotiation is completed, from configuration tasks to service delivery, fulfillment, and assurance (see Section 2.4 below).
したがって、決定論とは、ネットワークサービスの構造、設計、および配信方法を制御する機能と、ネットワーク内のトラフィックの転送先を最適化して、リソースの使用を最適化することを意味します。このドキュメントの以下のセクションでは明示的に述べられていませんが、決定論は、構成タスクからサービスの提供、履行、保証まで、サービスパラメータネゴシエーションが完了した後にサービスプロバイダーが実行する可能性のあるすべてのアクションの下にあります（以下のセクション2.4を参照）。
Such a definition assumes the introduction of a high level of automation in the overall service delivery and operation procedures.
このような定義では、サービスの提供および運用手順全体に高度な自動化が導入されていることを前提としています。
Because networking is software driven by nature, the above definition does not emphasize the claimed "software-defined" properties of SDN-labeled solutions.
ネットワーキングは本質的にソフトウェアによって駆動されるため、上記の定義は、SDNラベルの付いたソリューションの主張されている「ソフトウェア定義」の特性を強調していません。
SDN techniques can be classified into the following functional metadomains:
SDN技術は、次の機能メタドメインに分類できます。
o Techniques for the dynamic discovery of network topology, devices, and capabilities, along with relevant information and data models that are meant to precisely document such topology, devices, and their capabilities.
o ネットワークトポロジ、デバイス、および機能を動的に検出するためのテクニック、およびそのようなトポロジ、デバイス、およびそれらの機能を正確に文書化するための関連情報およびデータモデル。
o Techniques for exposing network services and their characteristics and for dynamically negotiating the set of service parameters that will be used to measure the level of quality associated with the delivery of a given service or a combination thereof. An example of this can be seen in [CPP].
o ネットワークサービスとその特性を公開し、特定のサービスまたはその組み合わせの配信に関連する品質レベルを測定するために使用されるサービスパラメータのセットを動的にネゴシエートするための手法。この例は[CPP]にあります。
o Techniques used by service-requirement-derived dynamic resource allocation and policy enforcement schemes, so that networks can be programmed accordingly. Decisions made to dynamically allocate resources and enforce policies are typically the result of the correlation of various inputs, such as the status of available resources in the network at any given time, the number of customer service subscription requests that need to be processed over a given period of time, the traffic forecasts, the possible need to trigger additional resource provisioning cycles according to a typical multi-year master plan, etc.
o サービス要件から派生した動的リソース割り当ておよびポリシー実施方式で使用される手法。これにより、ネットワークを適切にプログラムできます。リソースを動的に割り当ててポリシーを実施するために行われる決定は、通常、さまざまな入力の相関関係の結果です。たとえば、特定の時間におけるネットワークで利用可能なリソースのステータス、特定の時間で処理する必要があるカスタマーサービスサブスクリプション要求の数などです。期間、トラフィック予測、一般的な複数年のマスタープランに従って追加のリソースプロビジョニングサイクルをトリガーする必要性など。
o Dynamic feedback mechanisms that are meant to assess how efficiently a given policy (or a set thereof) is enforced from a service fulfillment and assurance perspective.
o 特定のポリシー（またはそのセット）がサービスの履行と保証の観点からどの程度効率的に実施されるかを評価するための動的フィードバックメカニズム。
The networking ecosystem has become awfully complex and highly demanding in terms of robustness, performance, scalability, flexibility, agility, etc. This means, in particular, that service providers and network operators must deal with such complexity and operate networking infrastructures that can evolve easily, remain scalable, guarantee robustness and availability, and are resilient to denial-of-service attacks.
ネットワーキングエコシステムは、堅牢性、パフォーマンス、スケーラビリティ、柔軟性、俊敏性などの点で、非常に複雑になり、非常に要求が厳しくなっています。これは、特に、サービスプロバイダーとネットワークオペレーターがこのような複雑さに対処し、簡単に進化するネットワーキングインフラストラクチャを運用する必要があることを意味します、拡張性を維持し、堅牢性と可用性を保証し、サービス拒否攻撃に対する耐性を備えています。
The introduction of new SDN-based networking features should obviously take into account this context, especially from a cost impact assessment perspective.
新しいSDNベースのネットワーキング機能の導入では、特にコスト影響評価の観点から、このコンテキストを明らかに考慮する必要があります。
SDN techniques are not the next big thing per se but rather a kind of rebranding of proposals that have been investigated for several years, like active or programmable networks [AN] [PN]. As a matter of fact, some of the claimed "new" SDN features have been already implemented (e.g., Network Management System (NMS) and Path Computation Element (PCE) [RFC4655]) and supported by vendors for quite some time.
SDN技術自体は次の大きなものではなく、アクティブネットワークやプログラム可能なネットワーク[AN] [PN]など、数年にわたって調査されてきた提案の一種のブランド変更です。実際のところ、主張されている「新しい」SDN機能の一部はすでに実装されており（たとえば、ネットワーク管理システム（NMS）とパス計算要素（PCE）[RFC4655]）、かなり長い間ベンダーによってサポートされています。
Some of these features have also been standardized (e.g., DNS-based routing [RFC1383]) that can be seen as an illustration of separated control and forwarding planes or Forwarding and Control Element Separation (ForCES) [RFC5810] [RFC5812].
これらの機能の一部（たとえば、DNSベースのルーティング[RFC1383]）も標準化されており、分離された制御プレーンと転送プレーン、または転送と制御要素の分離（ForCES）[RFC5810] [RFC5812]の図として見ることができます。
Also, the policy-based management framework [RFC2753] introduced in the early 2000's was designed to orchestrate available resources by means of a typical Policy Decision Point (PDP), which masters advanced offline traffic engineering capabilities. As such, this framework has the ability to interact with in-band software modules embedded in controlled devices (or not).
また、2000年代初頭に導入されたポリシーベースの管理フレームワーク[RFC2753]は、高度なオフライントラフィックエンジニアリング機能を習得する一般的なポリシー決定ポイント（PDP）を使用して、利用可能なリソースを調整するように設計されました。そのため、このフレームワークは、制御されたデバイスに組み込まれた（または組み込まれていない）帯域内ソフトウェアモジュールと対話する機能を備えています。
PDP is where policy decisions are made. PDPs use a directory service for policy repository purposes. The policy repository stores the policy information that can be retrieved and updated by the PDP. The PDP delivers policy rules to the Policy Enforcement Point (PEP) in the form of policy-provisioning information that includes configuration information.
PDPは、政策決定が行われる場所です。 PDPは、ポリシーリポジトリの目的でディレクトリサービスを使用します。ポリシーリポジトリには、PDPによって取得および更新できるポリシー情報が格納されます。 PDPは、構成情報を含むポリシープロビジョニング情報の形式でポリシールールをポリシー実施ポイント（PEP）に配信します。
PEP is where policy decisions are applied. PEPs are embedded in (network) devices, which are dynamically configured based upon the policy-formatted information that has been processed by the PEP. PEPs request configuration from the PDP, store the configuration information in the Policy Information Base (PIB), and delegate any policy decision to the PDP.
PEPは、ポリシー決定が適用される場所です。 PEPは（ネットワーク）デバイスに埋め込まれ、PEPによって処理されたポリシー形式の情報に基づいて動的に構成されます。 PEPはPDPから構成を要求し、構成情報をポリシー情報ベース（PIB）に格納し、ポリシー決定をPDPに委任します。
SDN techniques as a whole are an instantiation of the policy-based management framework. Within this context, SDN techniques can be used to activate capabilities on demand, to dynamically invoke network and storage resources, and to operate dynamically adaptive networks according to events (e.g., alteration of the network topology), triggers (e.g., dynamic notification of a link failure), etc.
SDN技術は全体として、ポリシーベースの管理フレームワークのインスタンス化です。このコンテキスト内で、SDN技術を使用して、オンデマンドで機能をアクティブ化し、ネットワークとストレージリソースを動的に呼び出し、イベント（ネットワークトポロジの変更など）、トリガー（動的な通知など）に応じて動的に適応型ネットワークを操作できます。リンク障害）など
SDN approaches should be holistic, i.e., global and network wide. It is not a matter of configuring devices one by one to enforce a specific forwarding policy. Instead, SDN techniques are about configuring and operating a whole range of devices at the scale of the network for automated service delivery [AUTOMATION], from service negotiation (e.g., [CPNP]) and creation (e.g., [SLA-EXCHANGE]) to assurance and fulfillment.
SDNアプローチは全体的である必要があります。つまり、グローバルでネットワーク全体です。特定の転送ポリシーを実施するためにデバイスを1つずつ構成することは問題ではありません。代わりに、SDN技術は、サービスネゴシエーション（[CPNP]）や作成（[SLA-EXCHANGE]など）から保証と履行。
Because the complexity of activating SDN capabilities is largely hidden from the end user and is software handled, a clear understanding of the overall ecosystem is needed to figure out how to manage this complexity and to what extent this hidden complexity does not have side effects on network operation.
SDN機能のアクティブ化の複雑さは、エンドユーザーからはほとんど隠されており、ソフトウェアで処理されるため、この複雑さを管理する方法と、この隠された複雑さがネットワークに悪影響を及ぼさない程度を把握するには、エコシステム全体を明確に理解する必要があります。操作。
As an example, SDN designs that assume a central decision-making entity must avoid single points of failure. They must not affect packet forwarding performances either (e.g., transit delays must not be impacted).
例として、中央の意思決定エンティティを想定したSDN設計では、単一障害点を回避する必要があります。それらは、パケット転送パフォーマンスにも影響を与えてはなりません（例えば、通過遅延は影響を受けてはなりません）。
SDN techniques are not necessary to develop new network services per se. The basic service remains as (IP) connectivity that solicits resources located in the network. SDN techniques can thus be seen as another means to interact with network service modules and invoke both connectivity and storage resources accordingly in order to meet service-specific requirements.
SDN手法自体は、新しいネットワークサービスを開発するために必要ではありません。基本的なサービスは、ネットワークにあるリソースを要求する（IP）接続として残ります。したがって、SDN技術は、サービス固有の要件を満たすために、ネットワークサービスモジュールとやり取りし、それに応じて接続リソースとストレージリソースの両方を呼び出す別の手段と見なすことができます。
By definition, SDN technique activation and operation remain limited to what is supported by embedded software and hardware. One cannot expect SDN techniques to support unlimited customizable features.
定義上、SDN技術のアクティブ化と操作は、組み込みソフトウェアとハードウェアがサポートするものに限定されたままです。 SDN技術が無制限のカスタマイズ可能な機能をサポートすることは期待できません。
Because several software modules may be controlled by external entities (typically, a PDP), there is a need for a means to make sure that what has been delivered complies with what has been negotiated. Such means belong to the set of SDN techniques.
複数のソフトウェアモジュールが外部エンティティ（通常はPDP）によって制御される可能性があるため、配信されたものが交渉されたものに準拠していることを確認する手段が必要です。このような手段は、一連のSDN技術に属します。
These typical policy-based techniques should interact with both Service Structuring engines (that are meant to expose the service characteristics and possibly negotiate those characteristics) and the network to continuously assess whether the experienced network behavior is compliant with the objectives set by the Service Structuring engine and those that may have been dynamically negotiated with the customer (e.g., as captured in a CPP [CPP] [CPNP]). This requirement applies to several regions of a network, including: 1. At the interface between two adjacent IP network providers.
これらの一般的なポリシーベースの手法は、サービス構造化エンジン（サービスの特性を公開し、場合によってはそれらの特性をネゴシエートすることを意味します）およびネットワークと相互作用して、経験豊富なネットワークの動作がサービス構造化エンジンによって設定された目的に準拠しているかどうかを継続的に評価する必要がありますおよび顧客と動的に交渉された可能性のあるもの（たとえば、CPP [CPP] [CPNP]でキャプチャされたもの）。この要件は、次のようなネットワークのいくつかの領域に適用されます。1. 2つの隣接するIPネットワークプロバイダー間のインターフェイス。
2. At the access interface between a service provider and an IP network provider.
2. サービスプロバイダーとIPネットワークプロバイダー間のアクセスインターフェイス。
3. At the interface between a customer and the IP network provider.
3. カスタマーとIPネットワークプロバイダー間のインターフェイス。
Ideally, a fully automated service delivery procedure, from negotiation, ordering, and order processing to delivery, assurance, and fulfillment, should be supported at the cost of implications that are discussed in Section 4.1. This approach also assumes widely adopted standard data and information models in addition to interfaces.
理想的には、交渉、注文、注文処理から配送、保証、履行までの完全に自動化されたサービス提供手順を、セクション4.1で説明する影響を犠牲にしてサポートする必要があります。このアプローチでは、インターフェースに加えて、広く採用されている標準のデータおよび情報モデルも想定しています。
Exposing open and programmable interfaces has a cost from both scalability and performance standpoints.
オープンでプログラム可能なインターフェースを公開すると、スケーラビリティとパフォーマンスの両方の観点からコストがかかります。
Maintaining hard-coded performance optimization techniques is encouraged. So is the use of interfaces that allow the direct control of some engines (e.g., routing and forwarding) without requiring any in-between adaptation layers (generic objects to vendor-specific command line interfaces (CLIs), for instance). Nevertheless, the use of vendor-specific access means to some engines that it could be beneficial from a performance standpoint, at the cost of increasing the complexity of configuration tasks.
ハードコードされたパフォーマンス最適化手法を維持することをお勧めします。そのため、中間のアダプテーションレイヤー（ベンダー固有のコマンドラインインターフェイス（CLI）などの汎用オブジェクト）を必要とせずに、一部のエンジン（ルーティングや転送など）の直接制御を可能にするインターフェイスの使用も同様です。それにもかかわらず、ベンダー固有のアクセスの使用は、構成タスクの複雑さを増すことを犠牲にして、パフォーマンスの観点からそれが有益であり得るいくつかのエンジンへのアクセスを意味します。
SDN techniques will have to accommodate vendor-specific components anyway. Indeed, these vendor-specific features will not cease to exist mainly because of the harsh competition.
とにかく、SDN技術はベンダー固有のコンポーネントに対応する必要があります。実際、これらのベンダー固有の機能は、主に厳しい競争のために存在しなくなることはありません。
The introduction of new functions or devices that may jeopardize network flexibility should be avoided or at least carefully considered in light of possible performance and scalability impacts. SDN-enabled devices will have to coexist with legacy systems.
ネットワークの柔軟性を危険にさらす可能性のある新しい機能またはデバイスの導入は、回避するか、少なくともパフォーマンスとスケーラビリティへの影響を考慮して慎重に検討する必要があります。 SDN対応デバイスは、レガシーシステムと共存する必要があります。
One single SDN network-wide deployment is, therefore, very unlikely. Instead, multiple instantiations of SDN techniques will be progressively deployed and adapted to various network and service segments.
したがって、単一のSDNネットワーク全体への展開はほとんどありません。代わりに、SDN技術の複数のインスタンス化が段階的に展開され、さまざまなネットワークおよびサービスセグメントに適応されます。
Empowering networking with in-band controllable modules may rely upon the OpenFlow protocol but also use other protocols to exchange information between a control plane and a data plane.
インバンドの制御可能なモジュールでネットワーキングを強化することは、OpenFlowプロトコルに依存するかもしれませんが、他のプロトコルを使用してコントロールプレーンとデータプレーンの間で情報を交換することもできます。
Indeed, there are many other candidate protocols that can be used for the same or even a broader purpose (e.g., resource reservation purposes). The forwarding of the configuration information can, for example, rely upon protocols like the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440], the Network Configuration Protocol (NETCONF) [RFC6241], COPS Usage for Policy Provisioning (COPS-PR) [RFC3084], Routing Policy Specification Language (RPSL) [RFC2622], etc.
実際、同じまたはより広い目的（たとえば、リソース予約目的）に使用できる他の多くの候補プロトコルがあります。構成情報の転送は、たとえば、パス計算要素（PCE）通信プロトコル（PCEP）[RFC5440]、ネットワーク構成プロトコル（NETCONF）[RFC6241]、ポリシープロビジョニングのCOPS使用（COPS- PR）[RFC3084]、ルーティングポリシー仕様言語（RPSL）[RFC2622]など
There is, therefore, no 1:1 relationship between OpenFlow and SDN. Rather, OpenFlow is one of the candidate protocols to convey specific configuration information towards devices. As such, OpenFlow is one possible component of the global SDN toolkit.
したがって、OpenFlowとSDNの間に1対1の関係はありません。むしろ、OpenFlowは特定の構成情報をデバイスに伝えるための候補プロトコルの1つです。したがって、OpenFlowは、グローバルSDNツールキットの1つの可能なコンポーネントです。
There are inevitable trade-offs to be found between operating the current networking ecosystem and introducing some SDN techniques, possibly at the cost of introducing new technologies. Operators do not have to choose between the two as both environments will have to coexist.
現在のネットワーキングエコシステムの運用と一部のSDN技術の導入の間には、おそらく新しいテクノロジーの導入を犠牲にして、避けられないトレードオフがあります。両方の環境が共存する必要があるため、オペレーターはこの2つを選択する必要はありません。
In particular, the following considerations cannot justify the deployment of SDN techniques:
特に、次の考慮事項では、SDN技術の展開を正当化できません。
o Fully flexible software implementations because the claimed flexibility remains limited by the software and hardware limitations, anyway.
o とにかく、主張された柔軟性はソフトウェアとハードウェアの制限によって制限されたままなので、完全に柔軟なソフトウェア実装。
o Fully modular implementations are difficult to achieve (because of the implicit complexity) and may introduce extra effort for testing, validation, and troubleshooting.
o 完全にモジュール化された実装は（暗黙的な複雑さのため）実現が難しく、テスト、検証、トラブルシューティングのために余分な労力が必要になる場合があります。
o Fully centralized control systems that are likely to raise some scalability issues. Distributed protocols and their ability to react to some events (e.g., link failure) in a timely manner remains a cornerstone of scalable networks. This means that SDN designs can rely upon a logical representation of centralized features (an abstraction layer that would support inter-PDP communications, for example).
o いくつかのスケーラビリティの問題を引き起こす可能性が高い完全に集中化された制御システム。分散プロトコルと、いくつかのイベント（リンク障害など）にタイムリーに対応するそれらの機能は、スケーラブルなネットワークの要です。これは、SDN設計が集中型機能の論理表現（たとえば、PDP間通信をサポートする抽象化レイヤー）に依存できることを意味します。
The path towards full automation is paved with numerous challenges and requirements, including:
完全な自動化への道は、次のような多くの課題と要件を備えています。
o Making sure automation is well implemented so as to facilitate testing (including validation checks) and troubleshooting.
o テスト（検証チェックを含む）とトラブルシューティングを容易にするために、自動化が適切に実装されていることを確認します。
* This suggests the need for simulation tools that accurately assess the impact of introducing a high level of automation in the overall service delivery procedure to avoid a typical "mad robot" syndrome, whose consequences can be serious from control and QoS standpoints, among others.
* これは、特にサービスとQoSの観点から重大な結果を招く可能性がある一般的な「マッドロボット」症候群を回避するために、サービス提供手順全体に高レベルの自動化を導入する影響を正確に評価するシミュレーションツールの必要性を示唆しています。
* This also suggests careful management of human expertise, so that network operators can use robust, flexible means to automate repetitive or error-prone tasks and then build on automation or stringing together multiple actions to create increasingly complex tasks that require less human interaction (guidance and input) to complete.
* これはまた、人間の専門知識の慎重な管理を示唆しているため、ネットワークオペレーターは、堅牢で柔軟な手段を使用して、繰り返しまたはエラーが発生しやすいタスクを自動化し、自動化または複数のアクションをつなぎ合わせることで構築して、人間の相互作用をあまり必要としないますます複雑なタスクを作成できます（ガイダンス入力）完了します。
o Simplifying and fostering service delivery, assurance, and fulfillment, as well as network failure detection, diagnosis, and root cause analysis for cost optimization.
o サービスの提供、保証、フルフィルメントの簡素化と促進、ネットワーク最適化のためのネットワーク障害の検出、診断、根本原因の分析。
* Such cost optimization relates to improved service delivery times as well as optimized human expertise (see above) and global, technology-agnostic service structuring and delivery procedures. In particular, the ability to inject new functions in existing devices should not assume a replacement of the said devices but rather allow smart investment capitalization.
* このようなコストの最適化は、サービス提供時間の改善、最適化された人間の専門知識（上記を参照）、技術にとらわれないグローバルなサービスの構造化および提供手順に関連しています。特に、既存のデバイスに新しい機能を注入する機能は、前述のデバイスの交換を想定するのではなく、スマートな投資資本化を可能にする必要があります。
* This can be achieved thanks to automation, possibly based upon a logically centralized view of the network infrastructure (or a portion thereof), yielding the need for highly automated topology, device and capabilities discovery means, and operational procedures.
* これは、おそらくネットワークインフラストラクチャ（またはその一部）の論理的に集中化されたビューに基づく自動化によって実現でき、高度に自動化されたトポロジ、デバイスと機能の検出手段、および運用手順が必要になります。
* The main intelligence resides in the PDP, which suggests that an important part of the SDN-related development effort should focus on a detailed specification of the PDP function, including algorithms and behavioral state machineries that are based upon a complete set of standardized data and information models.
* 主なインテリジェンスはPDPにあります。これは、SDN関連の開発作業の重要な部分は、標準化されたデータと情報の完全なセットに基づくアルゴリズムと動作状態機械を含む、PDP機能の詳細な仕様に焦点を当てるべきであることを示唆しています。モデル。
* These information models and data need to be carefully structured for efficiency and flexibility. This probably suggests that a set of simplified pseudo-blocks can be assembled as per the nature of the service to be delivered.
* これらの情報モデルとデータは、効率と柔軟性のために注意深く構造化する必要があります。これはおそらく、配信されるサービスの性質に従って、簡略化された疑似ブロックのセットを組み立てることができることを示唆しています。
o The need for abstraction layers -- clear interfaces between business actors and between layers, let alone cross-layer considerations, etc. Such abstraction layers are invoked within the context of service structuring and packaging and are meant to facilitate the emergence of the following:
o 抽象化レイヤーの必要性-ビジネスアクター間およびレイヤー間の明確なインターフェイス、クロスレイヤーの考慮事項はもちろんのこと。このような抽象化レイヤーは、サービスの構造化およびパッケージングのコンテキスト内で呼び出され、以下の出現を促進することを目的としています。
* IP connectivity service exposure to customers, peers, applications, content/service providers, etc. (an example of this can be seen in [CPP]).
* 顧客、ピア、アプリケーション、コンテンツ/サービスプロバイダーなどへのIP接続サービスの公開（この例は[CPP]にあります）。
* Solutions that accommodate IP connectivity service requirements with network engineering objectives.
* ネットワークエンジニアリングの目的を備えたIP接続サービス要件に対応するソリューション。
* Dynamically adaptive decision-making processes, which can properly operate according to a set of input data and metrics, such as current resource usage and demand, traffic forecasts and matrices, etc., all for the sake of highly responsive dynamic resource allocation and policy enforcement schemes.
* 動的に適応する意思決定プロセス。現在のリソースの使用状況と需要、トラフィックの予測とマトリックスなど、一連の入力データとメトリックに従って適切に動作し、応答性の高い動的なリソースの割り当てとポリシーの実施を目的としています。スキーム。
o Better accommodation of technologically heterogeneous networking environments through the following:
o 以下を介して、技術的に異機種混在のネットワーク環境への適応を改善します。
* Vendor-independent configuration procedures based upon the enforcement of vendor-agnostic generic policies instead of vendor-specific languages.
* ベンダー固有の言語ではなく、ベンダーに依存しない一般的なポリシーの適用に基づくベンダーに依存しない構成手順。
* Tools to aid manageability and orchestrate resources.
* 管理性を支援し、リソースを調整するためのツール。
* Avoiding proxies and privileging direct interaction with engines (e.g., routing and forwarding).
* プロキシを回避し、エンジンと直接やり取りする権限を与えます（ルーティングや転送など）。
Means to dynamically discover the functional capabilities of the devices that will be steered by a PDP intelligence for automated network service delivery need to be provided. This is because the acquisition of the information related to what the network is actually capable of will help structure the PDP intelligence so that policy provisioning information can be derived accordingly.
自動化されたネットワークサービス配信のためにPDPインテリジェンスによって操作されるデバイスの機能を動的に発見する手段を提供する必要があります。これは、ネットワークが実際に何ができるかに関連する情報を取得すると、PDPインテリジェンスを構築し、それに応じてポリシープロビジョニング情報を導出できるためです。
A typical example would consist in documenting a traffic engineering policy based upon the dynamic discovery of the various functions supported by the network devices, as a function of the services to be delivered, thus yielding the establishment of different routes towards the same destination depending on the nature of the traffic, the location of the functions that need to be invoked to forward such traffic, etc.
典型的な例は、ネットワークデバイスがサポートするさまざまな機能の動的な発見に基づくトラフィックエンジニアリングポリシーを、提供されるサービスの機能として文書化することです。これにより、同じ宛先に向けて異なるルートを確立できます。トラフィックの性質、そのようなトラフィックを転送するために呼び出す必要がある関数の場所など
Such dynamic discovery capability can rely upon the exchange of specific information by means of an IGP or BGP between network devices or between network devices and the PDP in legacy networking environments. The PDP can also send unsolicited commands towards network devices to acquire the description of their functional capabilities in return and derive network and service topologies accordingly.
このような動的検出機能は、レガシーネットワーキング環境でのネットワークデバイス間またはネットワークデバイスとPDP間のIGPまたはBGPによる特定の情報の交換に依存できます。また、PDPは非要請コマンドをネットワークデバイスに送信して、代わりに機能の説明を取得し、それに応じてネットワークおよびサービストポロジを導出することもできます。
Of course, SDN techniques (as introduced in Section 2.4) could be deployed in an IGP-/BGP-free networking environment, but the SDN bootstrapping procedure in such an environment still assumes the support of the following capabilities:
もちろん、SDG技術（セクション2.4で紹介）はIGP / BGPフリーのネットワーク環境に展開できますが、そのような環境でのSDNブートストラップ手順は、次の機能のサポートを前提としています。
o Dynamically discover SDN participating nodes (including the PDP) and their respective capabilities in a resilient manner, assuming the mutual authentication of the PDP and the participating devices Section 5. The integrity of the information exchanged between the PDP and the participating devices during the discovery phase must also be preserved;
o PDPと参加デバイスの相互認証を前提として、SDN参加ノード（PDPを含む）とそれぞれの機能を回復力のある方法で動的に検出します。セクション5。検出フェーズ中にPDPと参加デバイス間で交換される情報の整合性また、保存する必要があります。
o Dynamically connect the PDP to the participating nodes and avoid any forwarding loops;
o PDPを参加ノードに動的に接続し、転送ループを回避します。
o Dynamically enable network services as a function of the device capabilities and (possibly) what has been dynamically negotiated between the customer and the service provider;
o デバイスの機能と（場合によっては）顧客とサービスプロバイダーの間で動的にネゴシエートされた機能に応じて、ネットワークサービスを動的に有効にします。
o Dynamically check connectivity between the PDP and the participating nodes and between participating nodes for the delivery of a given network service (or a set thereof);
o 特定のネットワークサービス（またはそのセット）の配信について、PDPと参加ノードの間、および参加ノード間の接続を動的にチェックします。
o Dynamically assess the reachability scope as a function of the service to be delivered;
o 配信するサービスの関数として到達可能性の範囲を動的に評価します。
o Dynamically detect and diagnose failures, and proceed with corrective actions accordingly.
o 障害を動的に検出および診断し、それに応じて修正アクションを続行します。
Likewise, the means to dynamically acquire the descriptive information (including the base configuration) of any network device that may participate in the delivery of a given service should be provided so as to help the PDP structure the services that can be delivered as a function of the available resources, their location, etc.
同様に、特定のサービスの配信に参加する可能性のあるネットワークデバイスの説明情報（基本構成を含む）を動的に取得する手段を提供して、PDPの機能として配信可能なサービスを構築できるようにする必要があります。利用可能なリソース、それらの場所など
In IGP-/BGP-free networking environments, a specific bootstrap protocol may thus be required to support the aforementioned capabilities for proper PDP- and SDN-capable device operation, in addition to the possible need for a specific additional network that would provide discovery and connectivity features.
したがって、IGP / BGPフリーのネットワーク環境では、前述の機能をサポートするために、特定のブートストラッププロトコルが必要になる場合があります。これには、検出を提供する特定の追加ネットワークの必要性に加えて、適切なPDPおよびSDN対応デバイス操作が必要です。接続機能。
In particular, SDN design and operation in IGP-/BGP-free environments should provide performances similar to those of legacy environments that run an IGP and BGP. For example, the underlying network should remain operational even if connection with the PDP has been lost. Furthermore, operators should assess the cost of introducing a new, specific bootstrap protocol compared to the cost of integrating the aforementioned capabilities in existing IGP/BGP protocol machineries.
特に、IGP / BGPフリー環境でのSDNの設計と操作は、IGPとBGPを実行するレガシー環境と同様のパフォーマンスを提供する必要があります。たとえば、PDPとの接続が失われた場合でも、基盤となるネットワークは引き続き機能します。さらに、オペレーターは、前述の機能を既存のIGP / BGPプロトコルマシンに統合するコストと比較して、新しい特定のブートストラッププロトコルを導入するコストを評価する必要があります。
Since SDN-related features can be grafted into an existing network infrastructure, they may not be all enabled at once from a bootstrapping perspective; a gradual approach can be adopted instead.
SDN関連の機能は既存のネットワークインフラストラクチャに移植できるため、ブートストラップの観点からは、一度にすべてを有効にすることはできません。代わりに、段階的なアプローチを採用できます。
A typical deployment example would be to use an SDN decision-making process as an emulation platform that would help service providers and operators make appropriate technical choices before their actual deployment in the network.
典型的な導入例は、SDN意思決定プロセスをエミュレーションプラットフォームとして使用することです。これにより、サービスプロバイダーとオペレーターは、ネットワークに実際に導入する前に適切な技術的な選択を行うことができます。
Finally, the completion of the discovery procedure does not necessarily mean that the network is now fully operational. The operationality of the network usually assumes a robust design based upon resilience and high availability features.
最後に、検出手順が完了しても、ネットワークが完全に機能していることを必ずしも意味しません。ネットワークの運用性は、通常、復元力と高可用性機能に基づく堅牢な設計を前提としています。
From an Operations and Management (OAM) standpoint [RFC6291], running an SDN-capable network raises several issues such as those listed below:
運用と管理（OAM）の観点[RFC6291]の観点から、SDN対応のネットワークを実行すると、次のようないくつかの問題が発生します。
o How do SDN service and network management blocks interact? For example, how the results of the dynamic negotiation of service parameters with a customer or a set thereof over a given period of time will affect the PDP decision-making process (resource allocation, path computation, etc.).
o SDNサービスとネットワーク管理ブロックはどのように相互作用しますか？たとえば、特定の期間における顧客またはそのセットとのサービスパラメータの動的ネゴシエーションの結果がPDPの意思決定プロセス（リソース割り当て、パス計算など）にどのように影響するかなどです。
o What should be the appropriate OAM tools for SDN network operation (e.g., to check PDP or PEP reachability)?
o SDNネットワーク操作（PDPまたはPEPの到達可能性を確認するなど）に適したOAMツールは何ですか？
o How can performance (expressed in terms of service delivery time, for example) be optimized when the activation of software modules is controlled by an external entity (typically a PDP)?
o ソフトウェアモジュールのアクティブ化が外部エンティティ（通常はPDP）によって制御されている場合、パフォーマンス（サービス提供時間などで表現される）をどのように最適化できますか？
o To what extent does an SDN implementation ease network manageability, including service and network diagnosis?
o SDN実装は、サービスやネットワーク診断など、ネットワークの管理性をどの程度容易にしますか？
o Should the "control and data plane separation" principle be applied to the whole network or a portion thereof, as a function of the nature of the services to be delivered or by taking into account the technology that is currently deployed?
o 「制御とデータプレーンの分離」の原則は、配信するサービスの性質に応じて、または現在展開されているテクノロジーを考慮して、ネットワーク全体またはその一部に適用する必要がありますか？
o What is the impact on the service provider's testing procedures and methodologies (that are used during validation and pre-deployment phases)? Particularly, (1) how test cases will be defined and executed when the activation of customized modules is supported, (2) what the methodology is to assess the behavior of SDN-controlled devices, (3) how test regression will be conducted, (4) etc.
o サービスプロバイダーのテスト手順と方法（検証と展開前のフェーズで使用される）への影響は何ですか？特に、（1）カスタマイズされたモジュールのアクティブ化がサポートされている場合のテストケースの定義および実行方法、（2）SDN制御デバイスの動作を評価する方法論、（3）テスト回帰の実行方法、（ 4）など
o How do SDN techniques impact service fulfillment and assurance? How the resulting behavior of SDN devices (completion of configuration tasks, for example) should be assessed against what has been dynamically negotiated with a customer. How to measure the efficiency of dynamically enforced policies as a function of the service that has been delivered. How to measure that what has been delivered is compliant with what has been negotiated. What the impact is of SDN techniques on troubleshooting practice.
o SDN技術はサービスの履行と保証にどのように影響しますか？ SDNデバイスの結果としての動作（構成タスクの完了など）を、顧客と動的に交渉されたものに対してどのように評価するか。動的に適用されたポリシーの効率を、提供されたサービスの関数として測定する方法。配信されたものが交渉されたものに準拠していることを測定する方法。トラブルシューティングの実践におけるSDN技術の影響は何ですか。
o Is there any risk to operate frozen architectures because of potential interoperability issues between a controlled device and an SDN controller?
o 制御されたデバイスとSDNコントローラー間の潜在的な相互運用性の問題により、凍結されたアーキテクチャーを操作するリスクはありますか？
o How does the introduction of SDN techniques affect the lifetime of legacy systems? Is there any risk of (rapidly) obsoleting existing technologies because of their hardware or software limitations?
o SDN技術の導入は、レガシーシステムの寿命にどのように影響しますか？ハードウェアまたはソフトウェアの制限により、既存のテクノロジーが（急速に）廃止されるリスクはありますか？
The answers to the above questions are very likely to be service provider specific, depending on their technological and business environments.
上記の質問に対する答えは、技術的およびビジネス環境によっては、サービスプロバイダー固有である可能性が非常に高いです。
The proposed SDN definition in Section 2.3 assumes an intelligence that may reside in the control or the management planes (or both). This intelligence is typically represented by a Policy Decision Point (PDP) [RFC2753], which is one of the key functional components of the policy-based management framework.
セクション2.3で提案されているSDN定義は、コントロールプレーンまたは管理プレーン（またはその両方）に存在する可能性のあるインテリジェンスを前提としています。このインテリジェンスは通常、ポリシーベースの管理フレームワークの主要な機能コンポーネントの1つであるポリシー決定ポイント（PDP）[RFC2753]で表されます。
SDN networking, therefore, relies upon PDP functions that are capable of processing various input data (traffic forecasts, outcomes of negotiation between customers and service providers, resource status as depicted in appropriate information models instantiated in the PIB, etc.) to make appropriate decisions.
したがって、SDNネットワーキングは、さまざまな入力データ（トラフィック予測、顧客とサービスプロバイダー間のネゴシエーションの結果、PIBでインスタンス化された適切な情報モデルに示されているリソースステータスなど）を処理できるPDP機能に依存して、適切な決定を行います。
The design and the operation of such PDP-based intelligence in a scalable manner remains a part of the major areas that need to be investigated.
このようなPDPベースのインテリジェンスの設計と運用は、スケーラブルな方法で、調査が必要な主要な領域の一部として残っています。
To avoid centralized design schemes, inter-PDP communication is likely to be required, and corresponding issues and solutions should be considered. Several PDP instances may thus be activated in a given domain. Because each of these PDP instances may be responsible for making decisions about the enforcement of a specific policy (e.g., one PDP for QoS policy enforcement purposes, another one for security policy enforcement purposes, etc.), an inter-PDP communication scheme is required for global PDP coordination and correlation.
一元化された設計スキームを回避するには、PDP間通信が必要になる可能性が高く、対応する問題と解決策を検討する必要があります。したがって、特定のドメインでいくつかのPDPインスタンスをアクティブ化できます。これらの各PDPインスタンスは、特定のポリシーの実施に関する決定（たとえば、QoSポリシー実施のための1つのPDP、セキュリティポリシー実施のための別のPDPなど）を行う責任があるため、PDP間通信スキームが必要です。グローバルPDPの調整と相関。
Inter-domain PDP exchanges may also be needed for specific usages. Examples of such exchanges are as follows: (1) during the network attachment phase of a node to a visited network, the PDP operated by the visited network can contact the home PDP to retrieve the policies to be enforced for that node, and (2) various PDPs can collaborate in order to compute inter-domain paths that satisfy a set of traffic performance guarantees.
特定の用途では、ドメイン間のPDP交換も必要になる場合があります。そのような交換の例は次のとおりです。（1）訪問先ネットワークへのノードのネットワーク接続フェーズ中に、訪問先ネットワークによって操作されるPDPはホームPDPに接続して、そのノードに適用されるポリシーを取得できます。（2 ）さまざまなPDPが協調して、一連のトラフィックパフォーマンス保証を満たすドメイン間パスを計算できます。
The functional metadomains introduced in Section 2.4 assume the introduction of a high level of automation, from service negotiation to delivery and operation. Automation is the key to simplicity, but it must not be seen as a magic button that would be hit by a network administrator whenever a customer request has to be processed or additional resources need to be allocated.
セクション2.4で導入された機能メタドメインは、サービスの交渉から配信および運用まで、高度な自動化の導入を前提としています。自動化は単純化の鍵ですが、顧客の要求を処理する必要がある場合や追加のリソースを割り当てる必要がある場合にネットワーク管理者が押す魔法のボタンと見なしてはなりません。
The need for simplicity and adaptability, thanks to automated procedures, generally assumes some complexity that lies beneath automation.
自動化された手順のおかげで、単純さと適応性の必要性は、一般的に自動化の下にあるいくつかの複雑さを想定しています。
The combination of flexibility with software inevitably raises performance and scalability issues as a function of the number and the nature of the services to be delivered and their associated dynamics.
柔軟性とソフトウェアの組み合わせにより、パフォーマンスとスケーラビリティの問題が、提供されるサービスの数と性質、およびそれらに関連するダイナミクスの関数として必然的に発生します。
For example, networks deployed in Data Centers (DCs) and that rely upon OpenFlow switches are unlikely to raise important FIB scalability issues. Conversely, DC interconnect designs that aim to dynamically manage Virtual Machine (VM) mobility, possibly based upon the dynamic enforcement of specific QoS policies, may raise scalability issues.
たとえば、データセンター（DC）に展開され、OpenFlowスイッチに依存するネットワークでは、FIBの重要なスケーラビリティの問題が発生する可能性はほとんどありません。逆に、おそらく特定のQoSポリシーの動的な実施に基づいて、仮想マシン（VM）のモビリティを動的に管理することを目的としたDC相互接続設計は、スケーラビリティの問題を引き起こす可能性があります。
The claimed flexibility of SDN networking in the latter context will have to be carefully investigated by operators.
後者のコンテキストでのSDNネットワーキングの主張された柔軟性は、オペレーターが注意深く調査する必要があります。
Various risks are to be assessed such as:
以下のようなさまざまなリスクを評価する必要があります。
o Evaluating the risk of depending on a controller technology rather than a device technology.
o デバイステクノロジーではなくコントローラーテクノロジーに依存するリスクの評価。
o Evaluating the risk of operating frozen architectures because of potential interoperability issues between a controller and a controlled device.
o コントローラーと被制御デバイスとの間の潜在的な相互運用性の問題のために、凍結されたアーキテクチャーを操作するリスクを評価します。
o Assessing whether SDN-labeled solutions are likely to obsolete existing technologies because of hardware limitations. From a technical standpoint, the ability to dynamically provision resources as a function of the services to be delivered may be incompatible with legacy routing systems because of their hardware limitations, for example. Likewise, from an economical standpoint, the use of SDN solutions for the sake of flexibility and automation may dramatically impact Capital Expenditure (CAPEX) and Operational Expenditure (OPEX) budgets.
o ハードウェアの制限により、SDNラベルの付いたソリューションが既存のテクノロジーを廃止する可能性があるかどうかの評価。技術的な観点から見ると、配信するサービスの機能としてリソースを動的にプロビジョニングする機能は、ハードウェアの制限などにより、従来のルーティングシステムと互換性がない場合があります。同様に、経済的な観点から、柔軟性と自動化のためにSDNソリューションを使用すると、設備投資（CAPEX）と運用費用（OPEX）の予算に劇的な影響を与える可能性があります。
Security is an important aspect of any SDN design because it conditions the robustness and reliability of the interactions between network and applications people for efficient access control procedures and optimized protection of SDN resources against any kind of attack. In particular, SDN security policies [SDNSEC] should make sure that SDN resources are properly safeguarded against actions that may jeopardize network or application operations.
セキュリティは、効率的なアクセス制御手順とあらゆる種類の攻撃に対するSDNリソースの最適化された保護のためにネットワークとアプリケーションの関係者間の相互作用の堅牢性と信頼性を調整するため、SDN設計の重要な側面です。特に、SDNセキュリティポリシー[SDNSEC]は、SDNリソースがネットワークまたはアプリケーションの操作を危険にさらす可能性があるアクションから適切に保護されていることを確認する必要があります。
In particular, service providers should define procedures to assess the reliability of software modules embedded in SDN nodes. Such procedures should include the means to also assess the behavior of software components (under stress conditions), detect any exploitable vulnerability, reliably proceed with software upgrades, etc. These security guards should be activated during initial SDN node deployment and activation but also during SDN operation that implies software upgrade procedures.
特に、サービスプロバイダーは、SDNノードに埋め込まれたソフトウェアモジュールの信頼性を評価するための手順を定義する必要があります。このような手順には、ソフトウェアコンポーネントの動作（ストレス条件下）の評価、悪用可能な脆弱性の検出、ソフトウェアアップグレードの確実な続行などの手段も含める必要があります。これらのセキュリティガードは、初期SDNノードの展開とアクティブ化だけでなく、SDN中にもアクティブにする必要がありますソフトウェアのアップグレード手順を意味する操作。
Although these procedures may not be SDN-specific (e.g., operators are familiar with firmware updates with or without service disruption), it is worth challenging existing practice in light of SDN deployment and operation.
これらの手順はSDN固有ではない場合があります（たとえば、オペレーターは、サービスの中断の有無にかかわらず、ファームウェアの更新に慣れています）が、SDNの導入と運用の観点から、既存の方法に挑戦する価値があります。
Likewise, PEP-PDP interactions suggest the need to make sure that (1) a PDP is entitled to solicit PEPs, so that they can apply the decisions made by the said PDP, (2) a PEP is entitled to solicit a PDP for whatever reason (request for additional configuration information, notification about the results of a set of configuration tasks, etc.), (3) a PEP can accept decisions made by a PDP, and (4) communication between PDPs within a domain or between domains is properly secured (e.g., make sure a pair of PDPs are entitled to communicate with each other, make sure the confidentiality of the information exchanged between two PDPs can be preserved, etc.).
同様に、PEPとPDPの相互作用は、（1）PDPがPEPを要請する資格があり、そのPDPによって行われた決定を適用できるようにする必要があることを示唆している、（2）PEPは何でもPDPを要請する資格がある理由（追加の構成情報の要求、一連の構成タスクの結果に関する通知など）、（3）PEPがPDPによって行われた決定を受け入れることができる、（4）ドメイン内またはドメイン間のPDP間の通信が適切に保護されている（たとえば、PDPのペアが相互に通信する資格があることを確認する、2つのPDP間で交換される情報の機密性を保持できることを確認するなど）。
Many thanks to R. Barnes, S. Bryant, S. Dawkins, A. Farrel, S. Farrell, W. George, J. Halpern, D. King, J. Hadi Salim, and T. Tsou for their comments. Special thanks to P. Georgatos for the fruitful discussions on SDN Interconnection (SDNI) in particular.
R.バーンズ、S。ブライアント、S。ドーキンス、A。ファレル、S。ファレル、W。ジョージ、J。ハルパーン、D。キング、J。ハディサリム、T。ツウウのコメントに感謝します。特にSDN相互接続（SDNI）に関する実り多い議論についてP. Georgatosに特に感謝します。
[AN] Tennenhouse, D. and D. Wetherall, "Towards an Active Network Architecture", Multimedia Computing and Networking (MMCN), January 1996.
[AN] Tennenhouse、D。およびD. Wetherall、「アクティブネットワークアーキテクチャに向けて」、マルチメディアコンピューティングおよびネットワーキング（MMCN）、1996年1月。
[AUTOMATION] Boucadair, M. and C. Jacquenet, "Requirements for Automated (Configuration) Management", Work in Progress, January 2014.
[自動化] Boucadair、M。およびC.ジャクネット、「自動化（構成）管理の要件」、進行中の作業、2014年1月。
[CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, October 2013.
[CPNP] Boucadair、M。およびC. Jacquenet、「Connectivity Provisioning Negotiation Protocol（CPNP）」、Work in Progress、2013年10月。
[CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS Connectivity Provisioning Profile", Work in Progress, September 2012.
[CPP] Boucadair、M.、Jacquenet、C。、およびN. Wang、「IP / MPLS Connectivity Provisioning Profile」、Work in Progress、2012年9月。
[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, November 2013.
[LS-DISTRIB] Gredler、H.、Medved、J.、Previdi、S.、Farrel、A。、およびS. Ray、「BGPを使用したリンク状態およびTE情報の北限定分布」、作業中、 2013年11月。
[PN] Campbell, A., De Meer, H., Kounavis, M., Kazuho, M., Vincente, J., and D. Villela, "A Survey of Programmable Networks", ACM SIGCOMM Computer Communication Review, April 1999.
[PN]キャンベル、A、De Meer、H.、Kounavis、M、Kazuho、M、Vincente、J、およびD. Villela、「A Survey of Programmable Networks」、ACM SIGCOMM Computer Communication Review、1999年4月。
[RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992.
[RFC1383] Huitema、C。、「DNSベースのIPルーティングの実験」、RFC 1383、1992年12月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、Meyer、D.、Bates、T.、Karrenberg、D.、and M. Terpstra、 "Routing Policy Specification Language（RPSL ） "、RFC 2622、1999年6月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「A Framework for Policy-based Admission Control」、RFC 2753、2000年1月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[RFC3084]チャン、K、セリグソン、J、ダラム、D、ガイ、S、マックログリー、K、ヘルツォーク、S、ライヒマイヤー、F、ヤヴァトカール、A、スミス、「COPS Policy Provisioning（COPS-PR）の使用法」、RFC 3084、2001年3月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。とJL。 Le Roux、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5810] Doria、A.、Hadi Salim、J.、Haas、R.、Khosravi、H.、Wang、W.、Dong、L.、Gopal、R。、およびJ. Halpern、「転送および制御要素の分離（ForCES）プロトコル仕様」、RFC 5810、2010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「Forwarding and Control Element Separation（ForCES）Forwarding Element Model」、RFC 5812、2010年3月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R.、Bjorklund、M.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、2011年6月。
[SDNSEC] Hartman, S. and D. Zhang, "Security Requirements in the Software Defined Networking Model", Work in Progress, April 2013.
[SDNSEC] Hartman、S.およびD. Zhang、「ソフトウェア定義ネットワークモデルのセキュリティ要件」、作業中、2013年4月。
[SLA-EXCHANGE] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. Boucadair, "Inter-domain SLA Exchange", Work in Progress, November 2013.
[SLA-EXCHANGE] Shah、S.、Patel、K.、Bajaj、S.、Tomotaki、L。、およびM. Boucadair、「Inter-domain SLA Exchange」、Work in Progress、2013年11月。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Christian Jacquenet France Telecom Rennes France
Christian Jacquenet France Telecom Rennes France
EMail: christian.jacquenet@orange.com