RFC 7769 - Media Access Control (MAC) Address Withdrawal over Static Pseudowire 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7769
タイトル : RFC 7769 - 静的な疑似配線を介したメディアアクセス制御（MAC）アドレスの撤回
翻訳編集 : 自動生成

[要約] 要約： RFC 7769は、静的疑似ワイヤ上でのメディアアクセス制御（MAC）アドレスの取り消しに関するプロトコルを提案しています。このプロトコルは、ネットワーク上のMACアドレスの管理と制御を改善することを目的としています。目的： 1. 静的疑似ワイヤ上でのMACアドレスの取り消しを効率的に行うためのプロトコルを提供する。 2. ネットワーク上のMACアドレスの管理と制御を改善する。 3. ネットワークのパフォーマンスとセキュリティを向上させる。

Internet Engineering Task Force (IETF)                      S. Sivabalan
Request for Comments: 7769                                    S. Boutros
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                                  H. Shah
                                                             Ciena Corp.
                                                               S. Aldrin
                                                             Google Inc.
                                                           M. Venkatesan
                                                                 Comcast
                                                           February 2016

Media Access Control (MAC) Address Withdrawal over Static Pseudowire

静的な疑似配線を介したメディアアクセス制御（MAC）アドレスの撤回

Abstract

概要

This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.

このドキュメントでは、疑似配線（PW）関連付けられたチャネル（ACH）を使用してメディアアクセス制御（MAC）アドレスの撤回通知を通知するメカニズムを指定します。このような通知は、静的にプロビジョニングされたPWが仮想プライベートLANサービス（VPLS）または階層型仮想プライベートLANサービス（H-VPLS）環境に展開されている場合に役立ちます。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7769.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7769で入手できます。

著作権表示

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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  MAC Withdraw OAM Message  . . . . . . . . . . . . . . . . . .   4
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Operation of Sender . . . . . . . . . . . . . . . . . . .   6
     4.2.  Operation of Receiver . . . . . . . . . . . . . . . . . .   7
   5.  Security Consideration  . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  MPLS G-Ach Type . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Sequence Number TLV . . . . . . . . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

An LDP-based MAC address withdrawal mechanism is specified in [RFC4762] to remove dynamically learned MAC addresses when the source of those addresses can no longer forward traffic. This is accomplished by sending an LDP Address Withdraw Message with a MAC List TLV containing the MAC addresses to be removed from all other Provider Edge nodes over the LDP sessions. [RFC7361] describes an optimized MAC withdrawal mechanism that can be used to remove only the set of MAC addresses that need to be relearned in H-VPLS networks. [RFC7361] also describes optimized MAC withdrawal operations in PBB-VPLS networks.

[RFC4762]では、LDPベースのMACアドレス撤回メカニズムが指定されており、動的に学習されたMACアドレスの送信元がトラフィックを転送できなくなったときに、それらのMACアドレスを削除します。これは、LDPセッションを介して他のすべてのプロバイダーエッジノードから削除されるMACアドレスを含むMACリストTLVを含むLDPアドレスウィズドローメッセージを送信することで実現されます。 [RFC7361]は、H-VPLSネットワークで再学習する必要があるMACアドレスのセットのみを削除するために使用できる最適化されたMAC撤退メカニズムについて説明しています。 [RFC7361]は、PBB-VPLSネットワークでの最適化されたMAC引き出し操作についても説明しています。

A PW can be signaled via the LDP or can be statically provisioned. In the case of a static PW, an LDP-based MAC withdrawal mechanism cannot be used. This is analogous to the problem and solution described in [RFC6478] where a PW OAM (Operations, Administration, and Maintenance) message has been introduced to carry the PW status TLV using the in-band PW Associated Channel. In this document, we use a PW OAM message to withdraw MAC address(es) learned via a static PW.

PWは、LDPを介してシグナリングするか、静的にプロビジョニングできます。静的PWの場合、LDPベースのMAC引き出しメカニズムは使用できません。これは、[RFC6478]で説明されている問題と解決策に類似しており、インバンドPW関連チャネルを使用してPWステータスTLVを伝送するためにPW OAM（操作、管理、および保守）メッセージが導入されています。このドキュメントでは、PW OAMメッセージを使用して、静的PWを介して学習したMACアドレスを撤回します。

Thus, MAC withdraw signaling for static PW reuses the following concepts:

したがって、静的PWのMAC取り消しシグナルは、次の概念を再利用します。

- in-band signaling mechanisms used by static PW status signaling and

- 静的PWステータスシグナリングと、

- MAC withdrawal mechanisms described by [RFC4762] and [RFC7361].

- [RFC4762]と[RFC7361]で説明されているMACの引き出しメカニズム。

MAC withdraw signaling is a best effort scheme. It is an attempt to optimize network convergence by reducing blackholes caused by PW failover for protected PWs. The protocol defined in this document addresses possible loss of the MAC withdraw signal due to network congestion, but does not guarantee delivery, as is the case for the LDP-based MAC withdraw signaling. In the event that MAC withdraw signaling does not reach the intended target, the fallback to MAC re-learning due to bi-directional traffic or as a last resort aging out of MAC addresses in the absence of frames from the sources, will resume the traffic via new PW path. Such fallbacks would cause temporary blackouts but does not render a network permanently unusable.

MAC撤退シグナリングは、ベストエフォート方式です。これは、保護されたPWのPWフェイルオーバーによって引き起こされるブラックホールを減らすことによって、ネットワークの収束を最適化する試みです。このドキュメントで定義されているプロトコルは、LDPベースのMAC撤退シグナリングの場合のように、ネットワークの輻輳によるMAC撤退信号の損失の可能性に対処しますが、配信を保証するものではありません。 MAC撤回シグナリングが目的のターゲットに到達しない場合、双方向トラフィックによるMAC再学習へのフォールバック、またはソースからのフレームがない場合にMACアドレスが期限切れになる最後の手段として、トラフィックが再開されます新しいPWパス経由。このようなフォールバックは一時的なブラックアウトを引き起こしますが、ネットワークを永続的に使用不能にすることはありません。

2. Terminology

2. 用語

The following terminology is used in this document:

このドキュメントでは、次の用語が使用されています。

ACK: Acknowledgement for MAC withdraw message

ACK：MAC取り消しメッセージの確認

LDP: Label Distribution Protocol

LDP：ラベル配布プロトコル

MAC: Media Access Control

MAC：メディアアクセスコントロール

MPLS: Multiprotocol Label Switching

MPLS：マルチプロトコルラベルスイッチング

PW: Pseudowire

説明：シュードビル

PW OAM: PW Operations, Administration, and Maintenance

PW OAM：PWの運用、管理、およびメンテナンス

TLV: Type, Length, and Value

TLV：タイプ、長さ、値

VPLS: Virtual Private LAN Services

VPLS：仮想プライベートLANサービス

In addition, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

さらに、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「オプション」のキーワードこの文書は、[RFC2119]で説明されているように解釈されます。

3. MAC Withdraw OAM Message

3. MAC撤回OAMメッセージ

LDP provides reliable packet transport for control plackets for dynamic PWs. This can be contrasted with static PWs that rely on retransmission and acknowledgments (ACKs) for reliable OAM packet delivery as described in [RFC6478]. The proposed solution for MAC withdrawal over a static PW also relies on retransmissions and ACKs. However, an ACK is mandatory. A given MAC withdrawal notification is sent as a PW OAM message, and the sender retransmits the message a configured number of times in the absence of an ACK response for the sequence-numbered message. The receiver removes the MAC address(es) for a given sequence-number MAC withdraw signaling message and sends the ACK response. The receipt of the same or lower sequence-number message is responded to with an ACK but does not cause removal of MAC addresses. A new TLV to carry the sequence number has been defined.

LDPは、動的PWの制御プラケットに信頼できるパケット転送を提供します。これは、[RFC6478]で説明されているように、信頼性の高いOAMパケット配信のために再送信と確認応答（ACK）に依存する静的PWとは対照的です。静的PWを介したMAC撤退の提案されたソリューションも、再送信とACKに依存しています。ただし、ACKは必須です。特定のMAC撤退通知はPW OAMメッセージとして送信され、送信者はシーケンス番号付きメッセージに対するACK応答がない場合、設定された回数だけメッセージを再送信します。レシーバーは、特定のシーケンス番号のMAC撤回シグナリングメッセージのMACアドレスを削除し、ACK応答を送信します。同じまたはより低いシーケンス番号メッセージの受信は、ACKで応答されますが、MACアドレスは削除されません。シーケンス番号を伝送する新しいTLVが定義されました。

The format of the MAC address withdraw OAM message is shown in Figure 1. The MAC withdraw PW OAM message follows the same guidelines used in [RFC6478], whereby the first 4 bytes of the OAM message header are followed by a message-specific field and a set of TLVs relevant for the message. Since the MAC withdrawal PW OAM message is not refreshed forever, a MAC address withdraw OAM message MUST contain a "Sequence Number TLV"; otherwise, the entire message is dropped. It MAY contain the MAC Flush Parameter TLV defined in [RFC7361] when static PWs are deployed in H-VPLS and PBB-VPLS scenarios. The first 2 bits of the sequence-number TLV are reserved and MUST be set to 0 on transmit and ignored on receipt.

MACアドレスウィズドロウOAMメッセージのフォーマットを図1に示します。MACウィズドロウPW OAMメッセージは、[RFC6478]で使用されているのと同じガイドラインに従い、OAMメッセージヘッダーの最初の4バイトの後にメッセージ固有のフィールドとメッセージに関連する一連のTLV。 MAC撤回PW OAMメッセージは永久に更新されないため、MACアドレス撤回OAMメッセージには「シーケンス番号TLV」が含まれている必要があります。それ以外の場合は、メッセージ全体がドロップされます。静的PWがH-VPLSおよびPBB-VPLSシナリオで展開されている場合、[RFC7361]で定義されているMACフラッシュパラメータTLVを含めることができます。シーケンス番号TLVの最初の2ビットは予約されており、送信時に0に設定し、受信時に無視する必要があります。

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|   Reserved    |  MAC Withdraw OAM Msg (0x28)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved           |  TLV Length   |A|R| Flags     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Res|   Sequence No. TLV (0x1)  |  Sequence Number TLV Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         MAC List TLV                          |
      ~                MAC Flush Parameter TLV (optional)             ~
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: MAC Address Withdraw PW OAM Packet Format

図1：MACアドレスウィズドロウPW OAMパケットフォーマット

In this section, the MAC List TLV and MAC Flush Parameter TLV are collectively referred to as "MAC TLV(s)". The definition and processing rules of the MAC List TLV are described by [RFC4762], and the corresponding rules of the MAC Flush Parameter TLV are governed by [RFC7361].

このセクションでは、MACリストTLVとMACフラッシュパラメータTLVを総称して「MAC TLV」と呼びます。 MACリストTLVの定義と処理ルールは[RFC4762]で説明されており、MACフラッシュパラメータTLVの対応するルールは[RFC7361]で管理されています。

"TLV Length" is the total length of all TLVs in the message, and "Sequence Number TLV Length" is the length of the Sequence Number field.

「TLV Length」はメッセージ内のすべてのTLVの合計長であり、「Sequence Number TLV Length」は「Sequence Number」フィールドの長さです。

A single bit (called "A-bit") is set by a receiver to acknowledge receipt and processing of a MAC Address Withdraw OAM Message. In the acknowledge message, with the A-bit set, the MAC TLVs are excluded.

単一ビット（「Aビット」と呼ばれる）は、MACアドレスウィズドローOAMメッセージの受信と処理を確認するために受信者によって設定されます。確認メッセージでは、Aビットが設定されているため、MAC TLVは除外されます。

A single bit (called "R-bit") is set to indicate if the sender is requesting reset of the sequence numbers. The sender sets this bit when the pseudowire is restarted and has no local record of previous send and expected receive sequence numbers.

送信側がシーケンス番号のリセットを要求しているかどうかを示すために、単一ビット（「Rビット」と呼ばれる）が設定されます。送信者は、疑似配線が再起動されたときにこのビットを設定し、以前の送信のローカルレコードと予期される受信シーケンス番号がありません。

The Sequence Number TLV MUST be the first TLV in the message.

シーケンス番号TLVは、メッセージの最初のTLVである必要があります。

The lack of a reliable transport protocol for the in-band OAM necessitates a presence of sequencing and acknowledgement scheme so that the receiver can recognize newer message from retransmitted older messages. [RFC4385] describes the details of sequence-number handling, which includes overflow detection for a Sequence Number field size of 16 bits. This document leverages the same scheme with the two exemptions:

インバンドOAMの信頼できるトランスポートプロトコルがないため、受信者が再送信された古いメッセージから新しいメッセージを認識できるように、シーケンスと確認応答スキームが必要です。 [RFC4385]は、16ビットのシーケンス番号フィールドサイズのオーバーフロー検出を含む、シーケンス番号処理の詳細を説明しています。このドキュメントでは、2つの例外を除いて同じスキームを活用しています。

- the Sequence Number field is of size 32 bits.

- シーケンス番号フィールドのサイズは32ビットです。

- overflow detection is simplified such that a sequence number that exceeds 2,147,483,647 (0x7FFFFFFF) is considered an overflow and reset to 1.

- オーバーフロー検出は単純化されており、2,147,483,647（0x7FFFFFFF）を超えるシーケンス番号はオーバーフローと見なされ、1にリセットされます。

4. Operation

4. 操作

This section describes how the initial MAC Withdraw OAM Messages are sent and retransmitted, as well as how the messages are processed and retransmitted messages are identified.

このセクションでは、初期のMAC Withdraw OAMメッセージの送信方法と再送信方法、およびメッセージの処理方法と再送信メッセージの識別方法について説明します。

4.1. Operation of Sender

4.1. 送信者の操作

Each PW is associated with a counter to keep track of the sequence number of the transmitted MAC withdrawal messages. Whenever a node sends a new set of MAC TLVs, it increments the transmitted sequence-number counter and includes the new sequence number in the message. The transmit sequence number is initialized to 1 at the onset, after the wrap and after the sequence number reset request receipt. Hence the transmit sequence number is set to 2 in the first MAC withdraw message sent after the sequence number is initialized to 1.

各PWはカウンターと関連付けられており、送信されたMAC取り消しメッセージのシーケンス番号を追跡します。ノードが新しいMAC TLVのセットを送信するたびに、送信されたシーケンス番号カウンターを増分し、メッセージに新しいシーケンス番号を含めます。送信シーケンス番号は、ラップ後およびシーケンス番号リセット要求の受信後に、開始時に1に初期化されます。したがって、シーケンス番号が1に初期化された後に送信される最初のMAC取り消しメッセージで、送信シーケンス番号が2に設定されます。

The sender expects an ACK from the receiver within a time interval we call "Retransmit Time", which can be either a default (1 second) or a configured value. If the ACK does not arrive within the Retransmit Time, the sender retransmits the message with the same sequence number as the original message. The retransmission MUST cease when an ACK is received. In order to avoid continuous retransmissions in the absence of acknowledgements, a method of suppressing retransmissions MUST be implemented. A simple and well-used approach is to cease retransmission after a small number of transmissions. In the absence of an ACK response, a one second retransmission with two retries is RECOMMENDED. However, both the interval and the number of retries are a local matter that present no interworking issues; thus, the operator MAY configure different values. Alternatively, an increasing backoff delay with a larger number of retries MAY be implemented to improve scaling issues. Whilst there are no interworking issues with any of these methods, the implementer must be mindful to not introduce network congestion and must take into account the decaying value of the delayed MAC withdraw signaling against possible relearning due to bidirectional traffic or MAC timeout.

送信側は、「再送信時間」と呼ばれる時間間隔内に受信側からのACKを予期します。これは、デフォルト（1秒）または設定された値のいずれかです。 ACKが再送信時間内に到着しない場合、送信者は元のメッセージと同じシーケンス番号でメッセージを再送信します。 ACKを受信すると、再送信を停止する必要があります。確認応答がない場合の連続的な再送信を回避するために、再送信を抑制する方法を実装する必要があります。シンプルでよく使用されるアプローチは、少数の送信後に再送信を停止することです。 ACK応答がない場合、2回の再試行を伴う1秒の再送信が推奨されます。ただし、間隔と再試行回数はどちらもローカルな問題であり、相互運用の問題はありません。したがって、オペレーターは異なる値を構成できます（MAY）。あるいは、スケーリングの問題を改善するために、より多くの再試行で増加するバックオフ遅延を実装してもよい（MAY）。これらの方法のいずれでもインターワーキングの問題はありませんが、実装者はネットワークの輻輳を導入しないように注意し、双方向トラフィックまたはMACタイムアウトが原因で発生する可能性のある再学習に対して、遅延MAC取り消しシグナルの減衰値を考慮する必要があります。

During the period of retransmission, if a need to send a new MAC withdraw message with updated sequence number arises, then retransmission of the older unacknowledged withdraw message MUST be suspended and retransmit time for the new sequence number MUST be initiated. In essence, a sender engages in retransmission logic only for the most recently sent withdraw message for a given PW.

再送信の期間中に、更新されたシーケンス番号で新しいMAC取り消しメッセージを送信する必要が生じた場合、古い未確認の取り消しメッセージの再送信を一時停止し、新しいシーケンス番号の再送信時間を開始する必要があります。本質的に、送信者は、特定のPWに対して最後に送信されたwithdrawメッセージに対してのみ再送信ロジックを実行します。

In the event that a pseudowire is deleted and re-added or the router is restarted with configuration, the local node may lose information about the previously sent sequence number. This becomes problematic for the remote peer as it will continue to ignore the received MAC withdraw messages with lower sequence numbers. In such cases, it is desirable to reset the sequence numbers at both ends of the pseudowire. The reset R-bit is set in the first MAC withdraw to notify the remote peer to reset the send and receive sequence numbers. The R-bit must be cleared in subsequent MAC withdraw messages after the acknowledgement is received.

疑似配線が削除されて再度追加された場合、または構成を使用してルーターが再起動された場合、ローカルノードは以前に送信されたシーケンス番号に関する情報を失う可能性があります。これはリモートピアにとって問題になります。これは、シーケンス番号の小さい受信MAC取り消しメッセージを無視し続けるためです。そのような場合、疑似配線の両端でシーケンス番号をリセットすることが望ましいです。リセットRビットは、最初のMAC撤回で設定され、リモートピアに送信および受信シーケンス番号をリセットするよう通知します。確認応答を受信した後、後続のMAC取り消しメッセージでRビットをクリアする必要があります。

4.2. Operation of Receiver

4.2. 受信機の操作

Each PW is associated with a register to keep track of the expected sequence number of the MAC withdrawal message and is initialized to 1. Whenever a MAC withdrawal message is received, and if the sequence number on the message is greater than the value in the register, the MAC addresses contained in the MAC TLVs are removed, and the register is updated with the received sequence number. The receiver sends an ACK whose sequence number is the same as that in the received message.

各PWはレジスターに関連付けられ、MAC取り消しメッセージの予期されるシーケンス番号を追跡し、1に初期化されます。MAC取り消しメッセージが受信されるたびに、メッセージのシーケンス番号がレジスターの値より大きい場合、MAC TLVに含まれるMACアドレスが削除され、受信したシーケンス番号でレジスタが更新されます。受信者は、シーケンス番号が受信したメッセージのシーケンス番号と同じであるACKを送信します。

If the sequence number in the received message is smaller than or equal to the value in the register, the MAC TLVs are not processed. However, an ACK with the received sequence number MUST be sent as a response. The receiver processes the ACK message as an acknowledgement for all the MAC withdraw messages sent up to the sequence number present in the ACK message and terminates retransmission.

受信したメッセージのシーケンス番号がレジスタの値以下の場合、MAC TLVは処理されません。ただし、受信したシーケンス番号を含むACKを応答として送信する必要があります。受信者は、ACKメッセージに存在するシーケンス番号まで送信されたすべてのMAC取り消しメッセージの確認応答としてACKメッセージを処理し、再送信を終了します。

The handling of the sequence number is described in Section 3.

シーケンス番号の処理については、セクション3で説明します。

A MAC withdraw message with the R-bit set MUST be processed by resetting the send and receive sequence number first. The rest of MAC withdraw message processing is performed as described above. The acknowledgement is sent with the R-bit cleared.

Rビットが設定されたMAC取り消しメッセージは、最初に送信および受信シーケンス番号をリセットすることによって処理する必要があります。 MAC withdrawメッセージ処理の残りの部分は、上記のように実行されます。確認はRビットがクリアされた状態で送信されます。

5. Security Consideration

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

The security measures described in [RFC4447], [RFC5085], and [RFC6073] are adequate for the proposed mechanism.

[RFC4447]、[RFC5085]、および[RFC6073]で説明されているセキュリティ対策は、提案されたメカニズムに対して適切です。

6. IANA Considerations

6. IANAに関する考慮事項

6.1. MPLS G-Ach Type

6.1. MPLS G-Achタイプ

IANA has assigned a new channel type (0x0028) from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry. The description of the new channel type is "MAC Withdraw OAM Message".

IANAは、「MPLS一般化関連チャネル（G-ACh）タイプ（疑似配線関連チャネルタイプを含む）」レジストリから新しいチャネルタイプ（0x0028）を割り当てました。新しいチャネルタイプの説明は「MAC Withdraw OAM Message」です。

6.2. Sequence Number TLV

6.2. シーケンス番号TLV

IANA has assigned a new TLV Type (0x0001) from the existing LDP "TLV Type Name Space" registry. The description for the new TLV Type is "Sequence Number TLV".

IANAは、既存のLDP "TLV Type Name Space"レジストリから新しいTLVタイプ（0x0001）を割り当てました。新しいTLVタイプの説明は「シーケンス番号TLV」です。

7. Normative References

7. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <http://www.rfc-editor.org/info/rfc4385>.

[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、DOI 10.17487 / RFC4385、2006年2月、<http://www.rfc-editor.org/info/rfc4385>。

[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.

[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、DOI 10.17487 / RFC4447、2006年4月、<http://www.rfc-editor.org/info/rfc4447>。

[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.

[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<http ：//www.rfc-editor.org/info/rfc4762>。

[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.

[RFC5085]ナドー、T。、編、およびC.ピニャタロ、編、「疑似配線仮想回線接続検証（VCCV）：疑似配線の制御チャネル」、RFC 5085、DOI 10.17487 / RFC5085、2007年12月、<http： //www.rfc-editor.org/info/rfc5085>。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。

[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.

[RFC6073]マティーニ、L。、メッツ、C。、ナドー、T。、ボッチ、M。、およびM.アイサウイ、「セグメント化された疑似配線」、RFC 6073、DOI 10.17487 / RFC6073、2011年1月、<http：// www .rfc-editor.org / info / rfc6073>。

[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, DOI 10.17487/RFC6478, May 2012, <http://www.rfc-editor.org/info/rfc6478>.

[RFC6478]マティーニ、L。、スワロー、G。、ヘロン、G。、およびM.ボッチ、「静的な疑似配線の疑似配線ステータス」、RFC 6478、DOI 10.17487 / RFC6478、2012年5月、<http：//www.rfc -editor.org/info/rfc6478>。

[RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D. Fedyk, "LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014, <http://www.rfc-editor.org/info/rfc7361>.

[RFC7361] Dutta、P.、Balus、F.、Stokes、O.、Calvignac、G。、およびD. Fedyk、「階層型仮想プライベートLANサービス（H-VPLS）での最適化されたMACアドレス撤回のためのLDP拡張機能」、 RFC 7361、DOI 10.17487 / RFC7361、2014年9月、<http://www.rfc-editor.org/info/rfc7361>。

Authors' Addresses

著者のアドレス

Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada

Shiva Sivabalan Cisco Systems、Inc. ೨೦೦೦革新的なドライブドライブ、オンタリオQ1 A ೮カナダ

   Email: msiva@cisco.com

Sami Boutros Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States

Sami Boutros Cisco Systems、Inc. 170 West Tasman Dr. San Jose、CA 95134アメリカ

   Email: sboutros@cisco.com

Himanshu Shah Ciena Corp. 3939 North First Street San Jose, CA 95134 United States

Himanshu Shah Ciena Corp. 3939 North First Street San Jose、CA 95134アメリカ合衆国

   Email: hshah@ciena.com

Sam Aldrin Google Inc.

サムアルドリングーグル株式会社

   Email: aldrin.ietf@gmail.com

Mannan Venkatesan Comcast 1800 Bishops Gate Blvd Mount Laurel, NJ 08075 United States

Mannan Venkatesan Comcast 1800 Bishops Gate Blvd Mount Laurel、NJ 08075アメリカ合衆国

   Email: mannan_venkatesan@cable.comcast.com