MPLSのすべての利点を高く評価している通信事業者や大企業は、ネットワーク上でいくつかのコントロールプレーンプロトコルを使用せざるを得ません。 IGP + LDPは、ネットワークのコアの事実上の標準になりました。 これに加えて、OSPFプロトコルは不透明LSAによって拡張可能であることが知られています。IS-ISプロトコルは、新しいTLVの追加により長年にわたって正常に拡張されています。 しかし、MPLSタグをIGPに直接追加するとどうなりますか？ そして、あまり柔軟でないRSVPを取り除くことは可能ですか？ catの下で最適化の支持者に尋ねます。









この記事では、MPLSの基本については説明していません。著者は、読者が少なくとも用語に精通していることを期待しています。



LDPとRSVPの何が問題になっていますか？ まず、追加のコントロールプレーンプロトコルであり、IGPと相互作用し、正しい順序で密接にやり取りする必要があります 。 したがって、シスコの用語でのldp igp sync



およびその他の優れたIGP-LDP相互運用性管理技術。 誤って設定されたインターフェイスは、トラフィックのドロップにつながる可能性があります。 このような問題は、診断および修正が必ずしも容易ではありません。 次に、コントロールプレーンプロトコルは機器のリソースを消費します。 特に、従来のIOSでは、OS全体が同じメモリスペースで実行されるため、追加のプロセスも危険です。 つまり、1つのアプリケーションのセグメンテーション違反により、デバイス全体がクラッシュする可能性があります。 理論的には。 実際、ほとんどのベンダーのLDPおよびRSVPは、安定して動作します。 しかし、私たちは、熱心なオプティマイザーとして、もちろんそれらを取り除きたいと思っています。 転送の観点から、MPLSおよびIPv6プロトコルを使用してセグメントルーティングを実装できることは言う価値があります。 これは、MPLSを使用した転送プレーンのみに関するものです。

LDPを取り除く

SPRINGワーキンググループは、ラベル配布プロトコルの機能をIGPに移行し、 セグメントに LSPを構築することを提案しました。 セグメントは、特定のルーターに対するLSPの一部（またはすべて）です。 専用の範囲を使用してラベルを割り当て、従来のプロトコルと重複しないようにします。 SRGB-セグメントルーティンググローバルブロックと呼ばれます。 このブロックは異なるデバイスで異なる場合がありますが、可能であれば、混乱しないように同じブロックを使用することをお勧めします。 ただし、特定のPEを実現するラベルは一意でなければなりません。 この場合、セグメント全体のラベルは変更されません。 スワップ操作はどのような場合でも実行され、入力ラベルと出力ラベルが一致するだけであることを理解することが重要です。 デフォルトでは、iOS XRデバイスはSRGBに値16000-23999を使用します。 また、ブロックは異なる場合があるため、ブロックに関する情報はIGPを介して通知されます。

ブロックを使用すると、明確になります。 しかし、ルータは特定のFECのラベル値にどのように同意しますか？ 各デバイスには、一意のSIDが設定されている必要があります-セグメント識別子。 後者については、ノードSIDと隣接SIDがあります-少し低いです。 デバイスループバックに割り当てられるラベルを決定するために、ノードSIDがSRGBの下の境界に追加されます。 たとえば、SRGBが16000で始まり、デバイスにSID 5が割り当てられている場合、デバイスのループバックを実現するラベルは16005です。ルートに沿ったすべてのデバイスはこのラベルを使用します（スワップ16005-> 16005）。

突然、ループバックについて話していたのはなぜですか？ 実際、SRは特定のPEデバイスへのパスを構築するためのテクノロジーです。 つまり、トランスポートラベルのことです。 また、PEデバイスに到達するとは、そのラップバックに到達することを意味します。 サービスラベルの配布と割り当ては、L2VPN、L3VPN、またはその他のテクノロジーであっても変わりません。 サービスを構築するには、すべて同じMP-BGPが必要になります。すべての同じサービスラベルは、スタックの下部に配置されます。



デバイスのSIDは一意でなければならないことをもう少し言いました。 だから、これは露骨な嘘です。 隣接SIDにはローカルな意味があります。 ルータは各SRネイバーの隣接SIDを自動的に生成し、値はSRGBと重複しません。 この場合、何も設定する必要はありません。 他のすべてと同様に、そのようなタグはIGPによって配布されます。 これにより、特定のインターフェイスを介してトラフィックを送信できます。 ラベルが一意でない場合、インターフェイスを指定する方法は？ ここではすべてが簡単です。このために、ラベルスタックが使用されます。最上位ラベルはノードSID、最下位ラベルは隣接SIDです。

RSVPを取り除く

LDPはすべての人に適しています。IGPが選択したパスをたどるだけで、帯域を予約する方法はわかりません。 IGPが選択したものとは異なるトラフィック転送パスを構築する必要がある場合、明示的なパスを持つRSVP-TEが役立ちます。 IGPに準拠した最適なパス以外のパスを構築する場合、SRはすぐにRSVP機能を置き換えることができます。パスを完全に記述するラベルスタックを作成するだけです。 たとえば、トラフィックをルーターAからルーターBに送信する場合、SIDルーターA、次にSIDルーターBはトランスポートラベルのスタックになります。









率直に言って、構成の観点からの変更はほとんどありません。明示的なパスは同じIPアドレスを使用します。 そして、すぐによくある質問への答え：はい、オーバーヘッドが増加しています。 10個のルーターのパスを正確に決定する必要がある場合、スタックには10個のタグがあります。 ただし、このようなシナリオは実際には非常にまれです。 通常、特定の問題を解決するには、数個のタグで十分です。





そして、ストリップを予約するには？ これではまだ難しいです。 これで、CSPFの起動に問題はありません。 問題は、帯域幅を予約するには、各LSPの予約済みPPの値を記述するルーターの状態が必要なことです。 したがって、ストリップ予約の概念には、PCEの概念の導入が必要です。



PCE-パス計算要素-PCEPを介してルーターと通信するコントローラー。 このコントローラは、CSPFを使用して、帯域幅属性も含めてTEトンネルを計算できます。 既存の組み合わせはPCEとSRだけではないことに注意してください。 PCEは、RSVP、LDPと連携し、ラベルを静的に割り当てることもできます。 一般的な場合、PCEのタスクは、PCEPプロトコルを介してデバイスに転送状態を直接設定することです。

もちろん、パスを計算するには、PCEは既存のトポロジを知っている必要があります。 PCEをトポロジの一部にする、つまりIGPドメインに接続することで、PCEにトポロジを通知できます。 別の方法は、コントローラとのBGP-LSセッションです。



PCEは、必要に応じて、インターフェイスの現在の負荷を追跡し、トンネルのパスを再構築できます。 つまり、この要素は、既存のMPLSネットワーク上でSDNコントローラーと呼ぶことができます。 ただし、PCEの簡単な説明でさえ、少なくとも別の記事のトピックです。 したがって、PCEPを何らかの形でサポートする一般的なオープンソースプロジェクトへのリンクをここに残します。これらはONOSとODLです。SRに戻ります。

結果は何ですか？

すべてが非常に美しく、楽観的に見えますが、それをどこに適用するのですか？ いくつかのシナリオを見てみましょう。



1. LDPプロトコルの置き換え。



帯域幅予約を使用する場合、PCEを使用せずにRSVPを置き換えることは困難であることがわかりました。 したがって、SRネットワークに要素を追加せずにRSVPを完全に置き換えるものとして、それを考慮しません。 LDPに関しては、理論的にはこのプロトコルをオフにして、トランスポートラベルをIGP経由で配布できます。 ただし、このシナリオでは、ネットワークを再設計するときに取る必要があるリスクを考えると、十分な利点はほとんどありません。 さらに、ネットワーク上のすべてのデバイスがSRを常にサポートするわけではありません。 これは、複数のデバイスがSRドメインとLDPドメインの境界にある場合、追加の構成を使用して解決できます。 ただし、このような構成が存在するという事実により、ソリューションの長所と短所についてさらに考えるようになります。 率直に言って、現在、LDPを単にSRに置き換える理由はありません。



2.トポロジに依存しないLFA。



LFAまたはIP FRRは、任意のトポロジでは機能しません。 たとえば、リングトポロジでは、どのパスもループにつながるため、ルーターはサイディングを計算できません。 ただし、MPLSでのカプセル化を使用すると、トラフィックはネイバーだけでなくリモートデバイスにもドロップされます。 ここで、SRには実用的な意味があります。 もちろん、同じ問題はRSVPを使用して解決できますが、SRを使用したソリューションはよりエレガントに見えます。



例として、すべてのルーター間のOSPFコストが同じである前述のリングトポロジを想像してください。 各ルーターが特定のパスのLFAを計算するとします。









ご覧のとおり、IP経由でルーティングする場合の唯一の代替方法はループにつながります。 つまり、純粋なIPネットワークでは、LFAを計算できません。 したがって、SRが完全である予約済みプレフィックスに少し近くトラフィックを「ドロップ」する必要があります。





3. SDN。



SRをPCEと組み合わせて使用​​します。 ここでは、RSVPを置き換え、バンドを動的に追跡し、サードパーティツールのAPIを整理できます。 もちろん、このリストは少なく、ネットワークにPCEを導入することで達成できるすべてのリストではありません。 しかし、トランスポートの観点からは、ネットワーク管理の柔軟性、イントラAS LSP（TE、L2VPNなどを含む）の構成の可能性、サービスの構成と展開の簡素化が主なものになります。 さらに、PCEはネットワークの再設計を必要とせず、既存のフォワーディングプレーン上で動作できます。



ここで私は再びSRから少し離れて苦しみました。 ただし、SR + PCEバンドルは非常に有望に見えます。 そして、セグメントルーティングがすべての利点を明らかにするのは、このバンドル内です。



4.大規模ネットワークでのトラフィック管理。



シスコには、 Unified MPLSと呼ばれる大規模なキャリアネットワークを構築するための重要なアプローチがあります。 別の用語では、同じアプローチはシームレスMPLSと呼ばれる場合があります。 SRを使用したネットワークは、このアプローチに対する優れた、より透明な代替手段となります。



Unified MPLSを最初から使用してネットワークを設計および構成するためにどれだけの労力が必要か想像できる場合は、SRがあなたのものかもしれません。

LDPとSRの相互作用

最後にこのセクションを意図的に残しました。 まず、SRとLDPが相互作用することは常に必要というわけではありません。 第二に、SRの助けを借りてどのタスクを解決できるかを理解してから、LDPとの相互作用の問題に進むとよいでしょう。



最も頻繁に解決される相互作用の問題は、LDPからSRに移行するとき、またはネットワーク上の一部のデバイスでSRがサポートされていないときに発生します。 iOS XRでは、SR設定は安全です。 デフォルトでは、LDP派生ラベルが優先されます。 LDPが道を行くためには、IGPプロセスでルータsegment-routing mpls sr-prefer



を伝える必要があります。 同時に、すべてのルーターでSRを一度に優先させる必要はありません。 このコマンドはローカルであり、SRプリファレンスの事実は他のネットワークデバイスとはまったく通信されません。



SRをサポートしないデバイスがある場合は、複数のデバイスをマッピングサーバーとして構成する必要があります 。 フォールトトレランスの理由だけでいくつかを言います-操作のために、SR / LDPネットワークの境界上の1つのデバイスだけで十分です。



マッピングサーバーはLDPによってラベルを受信し、SRの方法がわからないデバイスに代わってSIDをアナウンスします。 同時に、データプレーンはマッピングサーバーを通過しないでください。これはコントロールプレーンデバイスです。 サーバーが作成したすべてのマッピングは、IGPを介してクライアントに通知されます 。 LDPネットワークのマッピングを受信するには、各デバイスをクライアントとして構成する必要があります。



マッピング自体は手動で設定されます。 さらに、2つ以上のマッピングサーバーを使用する場合、それらのマッピングは同じように構成されます。 もちろん、誤って構成されたマッピングが原因でネットワークが切断されることはありませんが、事故が発生した場合、収束が損なわれる可能性があります。





マッピングサーバーを使用すると、TI LFAのLDPプロトコルで構築されたLSPを保護できます。 つまり、従来のプロトコルによってラベルが生成されるMPLSサービスは、SRを使用して保護できます。



LDPoSRやSRoLDPなど、LDPとSRの相互作用には多くのシナリオがあります。 以下のリンクのいずれかで、もう少し詳細な説明を見つけることができます。



これで、セグメントルーティングに関する私の短い話は終わりです。 この記事の資料では、SRのすべてのニュアンスを考慮しているわけではなく、舞台裏に多くを残していることに注意してください。 背後に残っているものの多くは、以下のリンクで見つけることができます。



ご清聴ありがとうございました。



IETFリソースへのリンク：



» SRドラフト

» PCEP



SRに関する非常に役立つリソース： Cisco SR

Cisco Liveの1つのセッション： セグメントルーティングの概要