[要約] RFC 8772は、中国モバイル、華為技術、中興通訊のブロードバンドネットワークゲートウェイ（BNG）の制御とユーザープレーンの分離プロトコル（S-CUSP）に関するものです。このRFCの目的は、BNGの制御とユーザープレーンの分離を容易にするためのプロトコルを提供することです。
Independent Submission S. Hu
Request for Comments: 8772 China Mobile
Category: Informational D. Eastlake 3rd
ISSN: 2070-1721 Futurewei Technologies
F. Qin
China Mobile
T. Chua
Singapore Telecommunications
D. Huang
ZTE
May 2020
The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)
China Mobile、Huawei、およびZTE Broadband Network Gateway（BNG）Simple Control and User Plane Separation Protocol（S-CUSP）
Abstract
概要
A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP). China Mobile, Huawei Technologies, and ZTE have developed a simple CUPS control channel protocol to support such communication: the Simple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.
固定有線アクセスネットワークのブロードバンドネットワークゲートウェイ（BNG）は、イーサネット中心のIPエッジルーターであり、加入者トラフィックの集約ポイントです。このようなBNGのコントロールとユーザープレーンの分離（CUPS）は、柔軟性とスケーラビリティを向上させますが、ユーザープレーン（UP）とコントロールプレーン（CP）の間でさまざまな通信を必要とします。 China Mobile、Huawei Technologies、およびZTEは、このような通信をサポートするためのシンプルなCUPS制御チャネルプロトコルを開発しました。シンプルコントロールおよびユーザープレーン分離プロトコル（S-CUSP）です。 S-CUSPはこのドキュメントで定義されています。
This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability.
このドキュメントはIETF標準ではなく、IETFの合意もありません。 S-CUSPは、その仕様をインターネットコミュニティで便利に利用できるようにするためにここに提示され、診断と相互運用性を可能にします。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8772.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8772で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Implementation Requirement Keywords
2.2. Terms
3. BNG CUPS Overview
3.1. BNG CUPS Motivation
3.2. BNG CUPS Architecture Overview
3.3. BNG CUPS Interfaces
3.3.1. Service Interface (Si)
3.3.2. Control Interface (Ci)
3.3.3. Management Interface (Mi)
3.4. BNG CUPS Procedure Overview
4. S-CUSP Protocol Overview
4.1. Control Channel Procedures
4.1.1. S-CUSP Session Establishment
4.1.2. Keepalive Timer and DeadTimer
4.2. Node Procedures
4.2.1. UP Resource Report
4.2.2. Update BAS Function on Access Interface
4.2.3. Update Network Routing
4.2.4. CGN Public IP Address Allocation
4.2.5. Data Synchronization between the CP and UP
4.3. Subscriber Session Procedures
4.3.1. Create Subscriber Session
4.3.2. Update Subscriber Session
4.3.3. Delete Subscriber Session
4.3.4. Subscriber Session Events Report
5. S-CUSP Call Flows
5.1. IPoE
5.1.1. DHCPv4 Access
5.1.2. DHCPv6 Access
5.1.3. IPv6 Stateless Address Autoconfiguration (SLAAC) Access
5.1.4. DHCPv6 and SLAAC Access
5.1.5. DHCP Dual-Stack Access
5.1.6. L2 Static Subscriber Access
5.2. PPPoE
5.2.1. IPv4 PPPoE Access
5.2.2. IPv6 PPPoE Access
5.2.3. PPPoE Dual-Stack Access
5.3. WLAN Access
5.4. L2TP
5.4.1. L2TP LAC Access
5.4.2. L2TP LNS IPv4 Access
5.4.3. L2TP LNS IPv6 Access
5.5. CGN (Carrier Grade NAT)
5.6. L3 Leased Line Access
5.6.1. Web Authentication
5.6.2. User Traffic Trigger
5.7. Multicast Service Access
6. S-CUSP Message Formats
6.1. Common Message Header
6.2. Control Messages
6.2.1. Hello Message
6.2.2. Keepalive Message
6.2.3. Sync_Request Message
6.2.4. Sync_Begin Message
6.2.5. Sync_Data Message
6.2.6. Sync_End Message
6.2.7. Update_Request Message
6.2.8. Update_Response Message
6.3. Event Message
6.4. Report Message
6.5. CGN Messages
6.5.1. Addr_Allocation_Req Message
6.5.2. Addr_Allocation_Ack Message
6.5.3. Addr_Renew_Req Message
6.5.4. Addr_Renew_Ack Message
6.5.5. Addr_Release_Req Message
6.5.6. Addr_Release_Ack Message
6.6. Vendor Message
6.7. Error Message
7. S-CUSP TLVs and Sub-TLVs
7.1. Common TLV Header
7.2. Basic Data Fields
7.3. Sub-TLV Format and Sub-TLVs
7.3.1. Name Sub-TLVs
7.3.2. Ingress-CAR Sub-TLV
7.3.3. Egress-CAR Sub-TLV
7.3.4. If-Desc Sub-TLV
7.3.5. IPv6 Address List Sub-TLV
7.3.6. Vendor Sub-TLV
7.4. Hello TLV
7.5. Keepalive TLV
7.6. Error Information TLV
7.7. BAS Function TLV
7.8. Routing TLVs
7.8.1. IPv4 Routing TLV
7.8.2. IPv6 Routing TLV
7.9. Subscriber TLVs
7.9.1. Basic Subscriber TLV
7.9.2. PPP Subscriber TLV
7.9.3. IPv4 Subscriber TLV
7.9.4. IPv6 Subscriber TLV
7.9.5. IPv4 Static Subscriber Detect TLV
7.9.6. IPv6 Static Subscriber Detect TLV
7.9.7. L2TP-LAC Subscriber TLV
7.9.8. L2TP-LNS Subscriber TLV
7.9.9. L2TP-LAC Tunnel TLV
7.9.10. L2TP-LNS Tunnel TLV
7.9.11. Update Response TLV
7.9.12. Subscriber Policy TLV
7.9.13. Subscriber CGN Port Range TLV
7.10. Device Status TLVs
7.10.1. Interface Status TLV
7.10.2. Board Status TLV
7.11. CGN TLVs
7.11.1. Address Allocation Request TLV
7.11.2. Address Allocation Response TLV
7.11.3. Address Renewal Request TLV
7.11.4. Address Renewal Response TLV
7.11.5. Address Release Request TLV
7.11.6. Address Release Response TLV
7.12. Event TLVs
7.12.1. Subscriber Traffic Statistics TLV
7.12.2. Subscriber Detection Result TLV
7.13. Vendor TLV
8. Tables of S-CUSP Codepoints
8.1. Message Types
8.2. TLV Types
8.3. TLV Operation Codes
8.4. Sub-TLV Types
8.5. Error Codes
8.6. If-Type Values
8.7. Access-Mode Values
8.8. Access Method Bits
8.9. Route-Type Values
8.10. Access-Type Values
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. To provide centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, the CU-separated (CP/UP-separated) BNG framework is described in a technical report [TR-384] from the Broadband Forum (BBF). The CU-separated service CP, which is responsible for user access authentication and setting forwarding entries in UPs, can be virtualized and centralized. The routing control and forwarding plane, i.e., the BNG UP (local), can be distributed across the infrastructure. Other structures can also be supported, such as the CP and UP being virtual or both being physical.
固定有線アクセスネットワークのブロードバンドネットワークゲートウェイ（BNG）は、イーサネット中心のIPエッジルーターであり、加入者トラフィックの集約ポイントです。一元化されたセッション管理、柔軟なアドレス割り当て、サブスクライバー管理容量の高いスケーラビリティ、およびコスト効率の高い冗長性を提供するために、ブロードバンドのテクニカルレポート[TR-384]でCU区切り（CP / UP区切り）BNGフレームワークが説明されていますフォーラム（BBF）。ユーザーアクセス認証とUPでの転送エントリの設定を担当するCUで分離されたサービスCPは、仮想化および集中化できます。ルーティング制御および転送プレーン、つまりBNG UP（ローカル）は、インフラストラクチャ全体に分散できます。 CPとUPが仮想である、または両方が物理であるなど、他の構造もサポートできます。
Note: In this document, the terms "user" and "subscriber" are used interchangeably.
注：このドキュメントでは、「ユーザー」と「サブスクライバー」という用語は同じ意味で使用されています。
This document specifies the Simple CU Separation Protocol (S-CUSP) for communications over the BNG control channel between a BNG CP and a set of UPs. S-CUSP is designed to be flexible and extensible so as to allow for easy addition of messages and data items, should further requirements be expressed in the future.
このドキュメントは、BNG CPとUPのセットの間のBNG制御チャネルを介した通信用のシンプルCU分離プロトコル（S-CUSP）を指定します。 S-CUSPは、メッセージとデータアイテムを簡単に追加できるように柔軟で拡張できるように設計されています。
This document is not an IETF standard and does not have IETF consensus. S-CUSP was designed by China Mobile, Huawei Technologies, and ZTE. It is presented here to make the S-CUSP specification conveniently available to the Internet community to enable diagnosis and interoperability.
このドキュメントはIETF標準ではなく、IETFの合意もありません。 S-CUSPは、China Mobile、Huawei Technologies、およびZTEによって設計されました。ここでは、S-CUSP仕様をインターネットコミュニティで便利に利用できるようにして、診断と相互運用性を実現するために示します。
At the time of writing this document, the BBF is working to produce [WT-459], which will describe an architecture and requirements for a CP and UP separation of a disaggregated BNG. Future work may attempt to show how the protocol described in this document addresses those requirements and may modify this specification to handle unaddressed requirements.
このドキュメントの執筆時点で、BBFは[WT-459]の作成に取り組んでいます。これは、分解されたBNGのCPおよびUP分離のアーキテクチャと要件を説明します。今後の作業では、このドキュメントで説明されているプロトコルがこれらの要件にどのように対処するかを示し、対処されていない要件を処理するようにこの仕様を変更する可能性があります。
This section specifies implementation requirement keywords and terms used in this document. S-CUSP messages are described in this document using Routing Backus-Naur Form (RBNF) as defined in [RFC5511].
このセクションでは、このドキュメントで使用される実装要件のキーワードと用語を指定します。このドキュメントでは、[RFC5511]で定義されているRouting Backus-Naur Form（RBNF）を使用してS-CUSPメッセージを説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section specifies terms used in this document.
このセクションでは、このドキュメントで使用される用語を指定します。
AAA: Authentication Authorization Accounting.
AAA：認証承認アカウンティング。
ACK: Acknowledgement message.
ACK：確認メッセージ。
BAS: Broadband Access Server, also known as a BBRAS, BNG, or BRAS.
BAS：BBRAS、BNG、またはBRASとも呼ばれるブロードバンドアクセスサーバー。
BNG: Broadband Network Gateway. A BNG (or Broadband Remote Access Server (BRAS)) routes traffic to and from broadband remote access devices such as digital subscriber line access multiplexers (DSLAM) on an Internet Service Provider's (ISP) network. BNG / BRAS can also be referred to as a BAS or BBRAS.
BNG：ブロードバンドネットワークゲートウェイ。 BNG（またはブロードバンドリモートアクセスサーバー（BRAS））は、インターネットサービスプロバイダー（ISP）ネットワーク上のデジタル加入者回線アクセスマルチプレクサー（DSLAM）などのブロードバンドリモートアクセスデバイスとの間のトラフィックをルーティングします。 BNG / BRASは、BASまたはBBRASとも呼ばれます。
BRAS: Broadband Remote Access Server, also known as a BAS, BBRAS, or BNG.
BRAS：BAS、BBRAS、またはBNGとも呼ばれるブロードバンドリモートアクセスサーバー。
CAR: Committed Access Rate.
CAR：認定アクセスレート。
CBS: Committed Burst Size.
CBS：認定バーストサイズ。
CGN: Carrier Grade NAT.
CGN：キャリアグレードNAT。
Ci: Control Interface.
Ci：制御インターフェース。
CIR: Committed Information Rate.
CIR：認定情報レート。
CoA: Change of Authorization.
CoA：権限の変更。
CP: Control Plane. CP is a user control management component that supports the management of the UP's resources such as the user entry and forwarding policy.
CP：コントロールプレーン。 CPは、ユーザーエントリや転送ポリシーなど、UPのリソースの管理をサポートするユーザーコントロール管理コンポーネントです。
CU: Control Plane / User Plane.
CU：コントロールプレーン/ユーザープレーン。
CUSP: Control and User Plane Separation Protocol.
先端：コントロールおよびユーザープレーン分離プロトコル。
DEI: Drop Eligibility Indicator as defined in [802.1Q]. A bit in a VLAN tag after the priority and before the VLAN ID. (This bit was formerly the CFI (Canonical Format Indicator).)
DEI：[802.1Q]で定義されている適格性インジケーターを削除します。優先順位の後、VLAN IDの前のVLANタグのビット。 （このビットは、以前はCFI（Canonical Format Indicator）でした。）
DHCP: Dynamic Host Configuration Protocol [RFC2131].
DHCP：動的ホスト構成プロトコル[RFC2131]。
dial-up: This refers to the initial connection messages when a new subscriber appears. The name is left over from when subscribers literally dialed up on a modem-equipped phone line but herein is applied to other initial connection techniques. Initial connection is frequently indicated by the receipt of packets over PPPoE [RFC2516] or IPoE.
ダイヤルアップ：これは、新しいサブスクライバーが表示されるときの初期接続メッセージを指します。名前は、加入者が文字通りモデムを備えた電話回線でダイヤルアップしたときから残っていますが、ここでは他の初期接続技術に適用されます。 PPPoE [RFC2516]またはIPoEを介したパケットの受信によって、初期接続が頻繁に示されます。
EMS: Element Management System.
EMS：Element Management System。
IPoE: IP over Ethernet.
IPoE：IP over Ethernet。
L2TP: Layer 2 Tunneling Protocol [RFC2661].
L2TP：Layer 2 Tunneling Protocol [RFC2661]。
LAC: L2TP Access Concentrator.
LAC：L2TPアクセスコンセントレータ。
LNS: L2TP Network Server.
LNS：L2TPネットワークサーバー。
MAC: 48-bit Media Access Control address [RFC7042].
MAC：48ビットメディアアクセスコントロールアドレス[RFC7042]。
MANO: Management and Orchestration.
MANO：管理とオーケストレーション。
Mi: Management Interface.
Mi：管理インターフェース。
MSS: Maximum Segment Size.
MSS：最大セグメントサイズ。
MRU: Maximum Receive Unit.
MRU：最大受信ユニット。
NAT: Network Address Translation [RFC3022].
NAT：ネットワークアドレス変換[RFC3022]。
ND: Neighbor Discovery.
ND：近隣探索。
NFV: Network Function Virtualization.
NFV：ネットワーク機能仮想化。
NFVI: NFV Infrastructure.
NFVI：NFVインフラストラクチャ。
PBS: Peak Burst Size.
PBS：ピークバーストサイズ。
PD: Prefix Delegation.
PD：プレフィックス委任。
PIR: Peak Information Rate.
PIR：ピーク情報レート。
PPP: Point-to-Point Protocol [RFC1661].
PPP：ポイントツーポイントプロトコル[RFC1661]。
PPPoE: PPP over Ethernet [RFC2516].
PPPoE：PPP over Ethernet [RFC2516]。
RBNF: Routing Backus-Naur Form [RFC5511].
RBNF：バッカスナウアフォームのルーティング[RFC5511]。
RG: Residential Gateway.
RG：住宅用ゲートウェイ。
S-CUSP: Simple Control and User Plane Separation Protocol.
S-CUSP：シンプルコントロールおよびユーザープレーン分離プロトコル。
Subscriber: The remote user gaining network accesses via a BNG.
加入者：BNGを介してネットワークアクセスを取得するリモートユーザー。
Si: Service Interface.
Si：サービスインターフェイス。
TLV: Type-Length-Value. See Sections 7.1 and 7.3.
TLV：Type-Length-Value。セクション7.1および7.3を参照してください。
UP: User Plane. UP is a network edge and user policy implementation component. The traditional router's control plane and forwarding plane are both preserved on BNG devices in the form of a user plane.
UP：ユーザープレーン。 UPは、ネットワークエッジおよびユーザーポリシー実装コンポーネントです。従来のルーターのコントロールプレーンとフォワーディングプレーンは、どちらもユーザープレーンの形式でBNGデバイスに保持されます。
URPF: Unicast Reverse Path Forwarding.
URPF：ユニキャストリバースパス転送。
User: Equivalent to "customer" or "subscriber".
ユーザー：「顧客」または「サブスクライバー」に相当します。
VRF: Virtual Routing and Forwarding.
VRF：仮想ルーティングおよび転送。
The rapid development of new services, such as 4K TV, Internet of Things (IoT), etc., and increasing numbers of home broadband service users present some new challenges for BNGs such as:
4K TV、モノのインターネット（IoT）などの新しいサービスの急速な発展と、ホームブロードバンドサービスユーザーの増加により、BNGには次のような新たな課題が生じています。
Low resource utilization: The traditional BNG acts as both a gateway for user access authentication and accounting and also an IP network's Layer 3 edge. The mutually affecting nature of the tightly coupled control plane and forwarding plane makes it difficult to achieve the maximum performance of either plane.
低いリソース使用率：従来のBNGは、ユーザーアクセス認証とアカウンティングのゲートウェイとして機能するほか、IPネットワークのレイヤー3エッジとしても機能します。密結合されたコントロールプレーンと転送プレーンの相互に影響する性質により、いずれかのプレーンの最大のパフォーマンスを達成することが困難になります。
Complex management and maintenance: Due to the large numbers of traditional BNGs, configuring each device in a network is very tedious when deploying global service policies. As the network expands and new services are introduced, this deployment mode will cease to be feasible as it is unable to manage services effectively and to rectify faults rapidly.
複雑な管理とメンテナンス：従来のBNGは多数あるため、グローバルサービスポリシーを展開する場合、ネットワーク内の各デバイスの構成は非常に面倒です。ネットワークが拡大し、新しいサービスが導入されると、サービスを効果的に管理できず、障害を迅速に修正できないため、この展開モードは実現できなくなります。
Slow service provisioning: The coupling of the CP and the forwarding plane, in addition to being a distributed network control mechanism, means that any new technology has to rely heavily on the existing network devices.
サービスのプロビジョニングが遅い：CPとフォワーディングプレーンの結合は、分散ネットワーク制御メカニズムであることに加えて、新しいテクノロジーは既存のネットワークデバイスに大きく依存する必要があります。
The framework for a cloud-based BNG with CU separation to address these challenges for fixed networks is described in [TR-384]. The main idea of CU separation is to extract and centralize the user management functions of multiple BNG devices, forming a unified and centralized CP. The traditional router's CP and forwarding plane are both preserved on BNG devices in the form of a UP.
固定ネットワークのこれらの課題に対処するためのCU分離を備えたクラウドベースのBNGのフレームワークは、[TR-384]で説明されています。 CU分離の主なアイデアは、複数のBNGデバイスのユーザー管理機能を抽出して集中化し、統一された集中化されたCPを形成することです。従来のルーターのCPと転送プレーンは、どちらもUPの形式でBNGデバイスに保持されます。
The functions in a traditional BNG can be divided into two parts: (1) the user access management function and (2) the routing function. The user access management function can be deployed as a centralized module or device, called the BNG Control Plane (BNG-CP). The routing function, which includes routing control and the forwarding engine, can be deployed in the form of the BNG User Plane (BNG-UP).
従来のBNGの機能は、（1）ユーザーアクセス管理機能と（2）ルーティング機能の2つの部分に分けることができます。ユーザーアクセス管理機能は、BNGコントロールプレーン（BNG-CP）と呼ばれる集中モジュールまたはデバイスとして展開できます。ルーティング制御と転送エンジンを含むルーティング機能は、BNGユーザープレーン（BNG-UP）の形で展開できます。
Figure 1 shows the architecture of a CU-separated BNG:
図1は、CUで分離されたBNGのアーキテクチャーを示しています。
+------------------------------------------------------------------+
| Neighboring policy and resource management systems |
| |
| +-------------+ +-----------+ +---------+ +----------+ |
| | AAA Server | |DHCP Server| | EMS | | MANO | |
| +-------------+ +-----------+ +---------+ +----------+ |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| CU-separated BNG system |
| +--------------------------------------------------------------+ |
| | +----------+ +----------+ +------++------++-----------+ | |
| | | Address | |Subscriber| | AAA ||Access|| UP | | |
| | |management| |management| | || mgt ||management | | |
| | +----------+ +----------+ +------++------++-----------+ | |
| | CP | |
| +--------------------------------------------------------------+ |
| |
| |
| |
| +---------------------------+ +--------------------------+ |
| | +------------------+ | | +------------------+ | |
| | | Routing control | | | | Routing control | | |
| | +------------------+ | ... | +------------------+ | |
| | +------------------+ | | +------------------+ | |
| | |Forwarding engine | | | |Forwarding engine | | |
| | +------------------+ UP | | +------------------+ UP| |
| +---------------------------+ +--------------------------+ |
+------------------------------------------------------------------+
Figure 1: Architecture of a CU-Separated BNG
図1：CUで分離されたBNGのアーキテクチャ
As shown in Figure 1, the BNG-CP could be virtualized and centralized, which provides benefits such as centralized session management, flexible address allocation, high scalability for subscriber management capacity, cost-efficient redundancy, etc. The functional components inside the BNG-CP can be implemented as Virtual Network Functions (VNFs) and hosted in an NFVI.
図1に示すように、BNG-CPは仮想化および一元化できます。これにより、一元化されたセッション管理、柔軟なアドレス割り当て、サブスクライバー管理容量の高いスケーラビリティ、コスト効率の高い冗長性などの利点が得られます。BNG- CPは、仮想ネットワーク機能（VNF）として実装し、NFVIでホストできます。
The UP management module in the BNG-CP centrally manages the distributed BNG-UPs (e.g., load balancing), as well as the setup, deletion, and maintenance of channels between CPs and UPs. Other modules in the BNG-CP, such as address management, AAA, etc., are responsible for the connection with external subsystems in order to fulfill those services. Note that the UP SHOULD support both physical and virtual network functions. For example, network functions related to BNG-UP L3 forwarding can be disaggregated and distributed across the physical infrastructure, and the other CP management functions in the CU-separated BNG can be moved into the NFVI for virtualization [TR-384].
BNG-CPのUP管理モジュールは、分散BNG-UP（ロードバランシングなど）、およびCPとUP間のチャネルのセットアップ、削除、およびメンテナンスを集中管理します。 BNG-CPの他のモジュール（アドレス管理、AAAなど）は、これらのサービスを実行するために外部サブシステムとの接続を担当します。 UP SHOULDは、物理ネットワーク機能と仮想ネットワーク機能の両方をサポートする必要があることに注意してください。たとえば、BNG-UP L3転送に関連するネットワーク機能は、物理インフラストラクチャ全体に分解して分散でき、CUで分離されたBNGの他のCP管理機能は、仮想化のためにNFVIに移動できます[TR-384]。
The details of the CU-separated BNG's function components are as follows:
CUで分離されたBNGの機能コンポーネントの詳細は次のとおりです。
The CP is responsible for the following:
CPは次のことを担当します。
* Address management: Unified address pool management and CGN subscriber address traceability management.
* アドレス管理：統合アドレスプール管理とCGNサブスクライバーアドレストレーサビリティ管理。
* AAA: This component performs Authentication, Authorization, and Accounting, together with RADIUS/Diameter. The BNG communicates with the AAA server to check whether the subscriber who sent an access request has network access authority. Once the subscriber goes online, this component (together with the Service Control component) implements accounting, data capacity limitation, and QoS enforcement policies.
* AAA：このコンポーネントは、RADIUS / Diameterとともに、認証、承認、およびアカウンティングを実行します。 BNGはAAAサーバーと通信して、アクセス要求を送信した加入者がネットワークアクセス権限を持っているかどうかを確認します。サブスクライバーがオンラインになると、このコンポーネント（およびサービスコントロールコンポーネント）は、アカウンティング、データ容量の制限、およびQoS実施ポリシーを実装します。
* Subscriber management: User entry management and forwarding policy management.
* サブスクライバー管理：ユーザーエントリ管理と転送ポリシー管理。
* Access management: Process user dial-up packets, such as PPPoE, DHCP, L2TP, etc.
* アクセス管理：PPPoE、DHCP、L2TPなどのユーザーダイヤルアップパケットを処理します。
* UP management: Management of UP interface status and the setup, deletion, and maintenance of channels between CP and UP.
* UP管理：UPインターフェースステータスの管理、およびCPとUP間のチャネルのセットアップ、削除、およびメンテナンス。
The UP is responsible for the following:
UPは次のことを担当します。
* Routing control functions: Responsible for instantiating routing forwarding plane (e.g., routing, multicast, MPLS, etc.).
* ルーティング制御機能：ルーティング転送プレーン（ルーティング、マルチキャスト、MPLSなど）のインスタンス化を担当します。
* Routing and service forwarding plane functions: Responsibilities include traffic forwarding, QoS, and traffic statistics collection.
* ルーティングおよびサービス転送プレーン機能：責任には、トラフィック転送、QoS、およびトラフィック統計収集が含まれます。
* Subscriber detection: Responsible for detecting whether a subscriber is still online.
* サブスクライバーの検出：サブスクライバーがまだオンラインかどうかを検出します。
The three interfaces defined below support the communication between the CP and UP. These are referred to as the Service Interface (Si), Control Interface (Ci), and Management Interface (Mi) as shown in Figure 2.
以下に定義する3つのインターフェースは、CPとUP間の通信をサポートします。これらは、図2に示すように、サービスインターフェイス（Si）、制御インターフェイス（Ci）、および管理インターフェイス（Mi）と呼ばれます。
+-----------------------------------+
| |
| BNG-CP |
| |
+--+--------------+--------------+--+
| | |
1. Service | 2. Control | 3. Management|
Interface | Interface | Interface |
(Si) | (Ci) | (Mi) |
| | |
| ___|___ |
| ___( )___ |
_|______( )______|_
( )
( Network/Internet )
(________ ________)
| (___ ___) |
| (_______) |
| | |
| | |
+--+--------------+--------------+--+
| |
| BNG-UP |
| |
+-----------------------------------+
Figure 2: Interfaces between the CP and UP of the BNG
図2：BNGのCPとUP間のインターフェース
For a traditional BNG (without CU separation), the user dial-up signals are terminated and processed by the CP of a BNG. When the CP and UP of a BNG are separated, there needs to be a way to relay these signals between the CP and the UP.
従来のBNG（CU分離なし）では、ユーザーのダイヤルアップ信号はBNGのCPによって終了および処理されます。 BNGのCPとUPが分離されている場合、CPとUPの間でこれらの信号を中継する方法が必要です。
The Si is used to establish tunnels between the CP and UP. The tunnels are responsible for relaying the PPPoE-, IPoE-, and L2TP-related control packets that are received from a Residential Gateway (RG) over those tunnels. An appropriate tunnel type is Virtual eXtensible Local Area Network (VXLAN) [RFC7348].
Siは、CPとUPの間にトンネルを確立するために使用されます。トンネルは、これらのトンネルを介してレジデンシャルゲートウェイ（RG）から受信したPPPoE、IPPoE、およびL2TP関連の制御パケットを中継する役割を果たします。適切なトンネルタイプは、Virtual eXtensible Local Area Network（VXLAN）[RFC7348]です。
The detailed definition of Si is out of scope for this document.
Siの詳細な定義は、このドキュメントの範囲外です。
The CP uses the Ci to deliver subscriber session states, network routing entries, etc., to the UP (see Section 6.2.7). The UP uses this interface to report subscriber service statistics, subscriber detection results, etc., to the CP (see Sections 6.3 and 6.4). A carrying protocol for this interface is specified in this document.
CPはCiを使用して、加入者セッション状態、ネットワークルーティングエントリなどをUPに配信します（セクション6.2.7を参照）。 UPはこのインターフェースを使用して、加入者サービス統計、加入者検出結果などをCPに報告します（セクション6.3および6.4を参照）。このインターフェイスの伝送プロトコルは、このドキュメントで指定されています。
The Network Configuration Protocol (NETCONF) [RFC6241] is the protocol used on the Mi between a CP and UP. It is used to configure the parameters of the Ci, Si, access interfaces, and QoS/ACL Templates. It is expected that implementations will make use of existing YANG models where possible but that new YANG models specific to S-CUSP will need to be defined. The definitions of the parameters that can be configured are out of scope for this document.
ネットワーク構成プロトコル（NETCONF）[RFC6241]は、CPとUPの間のMiで使用されるプロトコルです。これは、Ci、Si、アクセスインターフェイス、およびQoS / ACLテンプレートのパラメータを設定するために使用されます。実装は可能な限り既存のYANGモデルを利用することが予想されますが、S-CUSPに固有の新しいYANGモデルを定義する必要があります。設定可能なパラメータの定義は、このドキュメントの範囲外です。
The following numbered sequences (Figure 3) give a high-level view of the main BNG CUPS procedures.
次の番号付きシーケンス（図3）は、主なBNG CUPS手順の概要を示しています。
RG UP CP AAA
| |Establish S-CUSP Channel| |
| 1|<---------------------->| |
| | | |
| | Report board interface | |
| | information | |
| 2|------to CP via Ci----->| |
| | | |
| | Update BAS function | |
| 3| request/response | |
| |<-----on UP via Ci----->| |
| | | |
| | Update network routing | |
| | request/response | |
| 4|<------- via Ci-------->| |
| Online Req | | |
5.1|-------------->| | |
| | Relay the Online Req | |
| 5.2|-----to CP via Si------>| Authentication|
| | | Req/Rep |
| | 5.3|<------------->|
| | Send the Online Rep | |
| 5.4|<----to UP via Si-------| |
| | | |
| | Create subscriber | |
| | session on UP | |
| 5.5|<--------via Ci-------->| |
| Online Rep | | |
5.6|<--------------| | |
| | | CoA Request |
| | 6.1|<--------------|
| | Update session on UP | |
| 6.2|<--------via Ci-------->| |
| | | CoA Response |
| Offline Req | 6.3|-------------->|
7.1|-------------->| | |
| | Relay the Offline Req | |
| 7.2|------to CP via Si----->| |
| | | |
| | Send the Offline Rep | |
| 7.3|<-----to UP via Si------| |
| Offline Rep | | |
7.4|<--------------| | |
| | Delete session on UP | |
| 7.5|<--------via Ci-------->| |
| | | |
| | Event report | |
| 8|---------via Ci-------->| |
| | | |
| | Data synchronization | |
| 9|<--------via Ci-------->| |
| | | |
| | CGN address allocation | |
| 10|<--------via Ci-------->| |
| | | |
Figure 3: BNG CUPS Procedures Overview
図3：BNG CUPS手順の概要
(1) S-CUSP session establishment: This is the first step of the BNG CUPS procedures. Once the Ci parameters are configured on a UP, it will start to set up S-CUSP sessions with the specified CPs. The detailed definition of S-CUSP session establishment can be found in Section 4.1.1.
（1）S-CUSPセッションの確立：これは、BNG CUPS手順の最初のステップです。 UPでCiパラメータが設定されると、指定されたCPでS-CUSPセッションのセットアップが開始されます。 S-CUSPセッション確立の詳細な定義はセクション4.1.1にあります。
(2) Board and interface report: Once the S-CUSP session is established between the UP and a CP, the UP will report status information on the boards and subscriber-facing interfaces of this UP to the CP. A board can also be called a Line/Service Process Unit (LPU/SPU) card. The subscriber-facing interfaces refer to the interfaces that connect the access network nodes (e.g., Optical Line Terminal (OLT), DSLAM, etc.). The CP can use this information to enable the Broadband Access Server (BAS) function (e.g., IPoE, PPPoE, etc.) on the specified interfaces. See Sections 4.2.1 and 7.10 for more details on resource reporting.
（2）ボードとインターフェースのレポート：UPとCPの間でS-CUSPセッションが確立されると、UPはボードとこのUPのサブスクライバー側インターフェースのステータス情報をCPに報告します。ボードは、ライン/サービスプロセスユニット（LPU / SPU）カードとも呼ばれます。加入者に面するインターフェイスは、アクセスネットワークノードを接続するインターフェイスを指します（たとえば、光回線ターミナル（OLT）、DSLAMなど）。 CPはこの情報を使用して、指定されたインターフェイスでブロードバンドアクセスサーバー（BAS）機能（例：IPoE、PPPoEなど）を有効にすることができます。リソースレポートの詳細については、セクション4.2.1および7.10を参照してください。
(3) BAS function enable: To enable the BAS function on the specified interfaces of a UP.
（3）BAS機能の有効化：UPの指定されたインターフェイスでBAS機能を有効にします。
(4) Subscriber network route advertisement: The CP will allocate one or more IP address blocks to a UP. Each address block contains a series of IP addresses. Those IP addresses will be allocated to subscribers who are dialing up from the UP. To enable other nodes in the network to learn how to reach the subscribers, the CP needs to notify the UP to advertise to the network the routes that can reach those IP addresses.
（4）加入者ネットワークルートアドバタイズメント：CPは、1つ以上のIPアドレスブロックをUPに割り当てます。各アドレスブロックには、一連のIPアドレスが含まれています。これらのIPアドレスは、UPからダイヤルアップする加入者に割り当てられます。ネットワーク内の他のノードがサブスクライバーに到達する方法を学習できるようにするには、CPがUPに通知して、これらのIPアドレスに到達できるルートをネットワークにアドバタイズする必要があります。
(5) 5.1-5.6 is a complete call flow of a subscriber dial-up (as defined in Section 4.3.1) process. When a UP receives a dial-up request, it will relay the request packet to a CP through the Si. The CP will parse the request. If everything is OK, it will send an authentication request to the AAA server to authenticate the subscriber. Once the subscriber passes the authentication, the AAA server will return a positive response to the CP. Then the CP will send the dial-up response packet to the UP, and the UP will forward the response packet to the subscriber (RG). At the same time, the CP will create a subscriber session on the UP, enabling the subscriber to access the network. For different access types, the process may be a bit different, but the high-level process is similar. For each access type, the detailed process can be found in Section 5.
（5）5.1-5.6は、（セクション4.3.1で定義されている）加入者ダイヤルアッププロセスの完全なコールフローです。 UPがダイヤルアップ要求を受信すると、要求パケットをSi経由でCPにリレーします。 CPは要求を解析します。すべて問題なければ、認証要求をAAAサーバーに送信して加入者を認証します。サブスクライバーが認証に合格すると、AAAサーバーはCPに肯定応答を返します。次に、CPはダイヤルアップ応答パケットをUPに送信し、UPは応答パケットを加入者（RG）に転送します。同時に、CPはUPで加入者セッションを作成し、加入者がネットワークにアクセスできるようにします。異なるアクセスタイプの場合、プロセスは少し異なる場合がありますが、高レベルのプロセスは似ています。アクセスタイプごとの詳細なプロセスについては、セクション5を参照してください。
(6) 6.1-6.3 is the sequence when updating an existing subscriber session. The AAA server initiates a Change of Authorization (CoA) and sends the CoA to the CP. The CP will then update the session according to the CoA. See Section 4.3.2 for more detail on CP messages updating UP tables.
（6）6.1-6.3は、既存の加入者セッションを更新するときのシーケンスです。 AAAサーバーは承認変更（CoA）を開始し、CoAをCPに送信します。その後、CPはCoAに従ってセッションを更新します。 UPテーブルを更新するCPメッセージの詳細については、セクション4.3.2を参照してください。
(7) 7.1-7.5 is the sequence for deleting an existing subscriber session. When a UP receives an Offline Request, it will relay the request to a CP through the Si. The CP will send back a response to the UP through the Si. The UP will then forward the Offline Response to the subscriber. Then the CP will delete the session on the UP through the Ci.
（7）7.1-7.5は、既存の加入者セッションを削除するためのシーケンスです。 UPがオフライン要求を受信すると、要求はSiを介してCPに中継されます。 CPはSiを通じてUPに応答を返します。その後、UPはオフライン応答をサブスクライバーに転送します。その後、CPはCiを介してUPのセッションを削除します。
(8) Event reports include the following two parts (more detail can be found in Section 4.3.4). Both are reported using the Event message:
（8）イベントレポートには次の2つの部分が含まれます（詳細はセクション4.3.4を参照）。どちらもイベントメッセージを使用して報告されます。
8.1. Subscriber Traffic Statistics Report
8.1. 加入者トラフィック統計レポート
8.2. Subscriber Detection Result Report
8.2. 加入者検出結果レポート
(9) Data synchronization: See Section 4.2.5 for more detail on CP and UP synchronization.
（9）データ同期：CPおよびUP同期の詳細については、セクション4.2.5を参照してください。
(10) CGN address allocation: See Section 4.2.4 for more detail on CGN address allocation.
（10）CGNアドレス割り当て：CGNアドレス割り当ての詳細については、セクション4.2.4を参照してください。
A UP is associated with a CP and is controlled by that CP. In the case of a hot-standby or cold-standby, a UP is associated with two CPs: the master CP and standby CP. The association between a UP and its CPs is implemented by dynamic configuration.
UPはCPに関連付けられ、そのCPによって制御されます。ホットスタンバイまたはコールドスタンバイの場合、UPはマスターCPとスタンバイCPの2つのCPに関連付けられます。 UPとそのCPの間の関連付けは、動的構成によって実装されます。
Once a UP knows its CPs, the UP starts to establish S-CUSP sessions with those CPs, as shown in Figure 4.
UPはそのCPを認識すると、図4に示すように、それらのCPとのS-CUSPセッションの確立を開始します。
UP CP
| TCP Session Establishment |
|<------------------------------->|
| |
| Hello (version, capability) |
|-------------------------------->|
| |
| Hello (version, capability) |
|<--------------------------------|
| |
Figure 4: S-CUSP Session Establishment
図4：S-CUSPセッションの確立
The S-CUSP session establishment consists of two successive steps:
S-CUSPセッションの確立は、次の2つのステップで構成されます。
(1) Establishment of a TCP connection (3-way handshake) [RFC793] between the CP and the UP using a configured port from the dynamic port range (49152-65535).
（1）動的ポート範囲（49152-65535）の構成済みポートを使用した、CPとUP間のTCP接続（3ウェイハンドシェイク）[RFC793]の確立。
(2) Establishment of an S-CUSP session over the TCP connection.
（2）TCP接続を介したS-CUSPセッションの確立。
Once the TCP connection is established, the CP and the UP initialize the S-CUSP session, during which the version and Keepalive timers are negotiated.
TCP接続が確立されると、CPとUPがS-CUSPセッションを初期化し、その間にバージョンとキープアライブタイマーがネゴシエートされます。
The version information (Hello TLV, see Section 7.4) is carried within Hello messages (see Section 6.2.1). A CP can support multiple versions, but a UP can only support one version; thus the version negotiation is based on whether a version can be supported by both the CP and the UP. If a CP or UP receives a Hello message that does not indicate a version supported by both, it responds with a Hello message containing an Error Information TLV to notify the peer of the Version-Mismatch error, and the session establishment phase fails.
バージョン情報（Hello TLV、セクション7.4を参照）は、Helloメッセージ（セクション6.2.1を参照）内で伝達されます。 CPは複数のバージョンをサポートできますが、UPは1つのバージョンしかサポートできません。したがって、バージョンネゴシエーションは、CPとUPの両方がバージョンをサポートできるかどうかに基づいています。 CPまたはUPが両方でサポートされているバージョンを示さないHelloメッセージを受信すると、エラー情報TLVを含むHelloメッセージで応答し、バージョンミスマッチエラーをピアに通知します。セッション確立フェーズは失敗します。
Keepalive negotiation is performed by carrying a Keepalive TLV in the Hello message. The Keepalive TLV includes a Keepalive timer and DeadTimer field. The CP and UP have to agree on the Keepalive Timer and DeadTimer. Otherwise, a subsequent Hello message with an Error Information TLV will be sent to its peer, and the session establishment phase fails.
キープアライブネゴシエーションは、HelloメッセージでキープアライブTLVを伝送することによって実行されます。キープアライブTLVには、キープアライブタイマーとDeadTimerフィールドが含まれています。 CPとUPは、キープアライブタイマーとデッドタイマーに同意する必要があります。そうでない場合、エラー情報TLVを含む後続のHelloメッセージがピアに送信され、セッション確立フェーズは失敗します。
The S-CUSP session establishment phase fails if the CP or UP disagree on the version and keepalive parameters or if one of the CP or UP does not answer after the expiration of the Establishment timer. When the S-CUSP session establishment fails, the TCP connection is promptly closed. Successive retries are permitted, but an implementation SHOULD make use of an exponential backoff session establishment retry procedure.
S-CUSPセッション確立フェーズは、CPまたはUPがバージョンとキープアライブパラメータについて同意しない場合、または確立タイマーの期限切れ後にCPまたはUPのいずれかが応答しない場合に失敗します。 S-CUSPセッションの確立に失敗すると、TCP接続はすぐに閉じられます。連続した再試行は許可されますが、実装では、指数バックオフセッション確立の再試行手順を使用する必要があります（SHOULD）。
The S-CUSP session timer values that need to be configured are summarized in Table 1.
設定する必要があるS-CUSPセッションタイマー値を表1にまとめます。
+---------------------+------------------+---------------+
| Timer Name | Range in Seconds | Default Value |
+=====================+==================+===============+
| Establishment Timer | 1-32767 | 45 |
+---------------------+------------------+---------------+
| Keepalive Timer | 0-255 | 30 |
+---------------------+------------------+---------------+
| DeadTimer | 1-32767 | 4 * Keepalive |
+---------------------+------------------+---------------+
Table 1: S-CUSP Session Timers
表1：S-CUSPセッションタイマー
Once an S-CUSP session has been established, a UP or CP may want to know that its S-CUSP peer is still connected.
S-CUSPセッションが確立されると、UPまたはCPは、そのS-CUSPピアがまだ接続されていることを知りたい場合があります。
Each end of an S-CUSP session runs a Keepalive timer. It restarts the timer every time it sends a message on the session. When the timer expires, it sends a Keepalive message. Thus, a message is transmitted at least as often as the value to which the Keepalive timer is reset, unless, as explained below, that value is the special value zero.
S-CUSPセッションの終了ごとにキープアライブタイマーが実行されます。セッションでメッセージを送信するたびにタイマーを再起動します。タイマーが期限切れになると、キープアライブメッセージが送信されます。したがって、メッセージは、キープアライブタイマーがリセットされる値と少なくとも同じ頻度で送信されます。ただし、以下で説明するように、その値が特別な値0である場合を除きます。
Each end of an S-CUSP session also runs a DeadTimer and restarts that DeadTimer whenever a message is received on the session. If the DeadTimer expires at an end of the session, that end declares the session dead and the session will be closed, unless their DeadTimer is set to the special value zero, in which case the session will not time out.
S-CUSPセッションの各終了でもDeadTimerが実行され、セッションでメッセージが受信されるたびにそのDeadTimerが再起動されます。 DeadTimerがセッションの終了時に期限切れになると、その終了はセッションの終了を宣言し、セッションが閉じられます。ただし、DeadTimerが特別な値0に設定されていない場合、セッションはタイムアウトしません。
The minimum value of the Keepalive timer is 1 second, and it is specified in units of 1 second. The RECOMMENDED default value is 30 seconds. The recommended default for the DeadTimer is four times the value of the Keepalive timer used by the remote peer. As above, the timers may be disabled by setting them to zero.
キープアライブタイマーの最小値は1秒で、1秒単位で指定されます。 RECOMMENDEDのデフォルト値は30秒です。 DeadTimerの推奨デフォルトは、リモートピアが使用するキープアライブタイマーの値の4倍です。上記のように、タイマーをゼロに設定すると、タイマーが無効になる場合があります。
The Keepalive timer and DeadTimer are negotiated through the Keepalive TLV carried in the Hello message.
キープアライブタイマーとデッドタイマーは、Helloメッセージで伝送されるキープアライブTLVを介してネゴシエートされます。
Once an S-CUSP session has been established between a CP and a UP, the UP reports the state information of the boards and access-facing interfaces on the UP to the CP, as shown in Figure 5. Report messages are unacknowledged and are assumed to be delivered because the session runs over TCP.
CPとUPの間でS-CUSPセッションが確立されると、図5に示すように、UPはボードとUP上のアクセス側インターフェイスの状態情報をCPに報告します。報告メッセージは未確認であり、想定されますセッションはTCPで実行されるため、配信されます。
The CP can use that information to activate/enable the BAS functions (e.g., IPoE, PPPoE, etc.) on the specified interfaces.
CPはその情報を使用して、指定されたインターフェースでBAS機能（例：IPoE、PPPoEなど）をアクティブ化/有効化できます。
In addition, the UP resource report may trigger a UP warm-standby process. In the case of warm-standby, a failure on a UP may trigger the CP to start a warm-standby process, by moving the online subscriber sessions to a standby UP and then directing the affected subscribers to access the Internet through the standby UP.
さらに、UPリソースレポートがUPウォームスタンバイプロセスをトリガーする場合があります。ウォームスタンバイの場合、UPで障害が発生すると、オンラインサブスクライバーセッションをスタンバイUPに移動し、影響を受けるサブスクライバーにスタンバイUPを介してインターネットにアクセスするように指示することで、CPがウォームスタンバイプロセスを開始することがあります。
UP CP
| Report Board Status |
|------to CP via Ci----->|
| |
| Report Interface Status|
|------to CP via Ci----->|
| |
Figure 5: UP Board and Interface Report
図5：UPボードとインターフェースのレポート
Board status information is carried in the Board Status TLV (Section 7.10.2), and interface status information is carried in the Interface Status TLV (Section 7.10.1). Both Board Status and Interface Status TLVs are carried in the Report message (Section 6.4).
ボードステータス情報は、Board Status TLV（セクション7.10.2）で伝達され、インターフェースステータス情報は、Interface Status TLV（セクション7.10.1）で伝達されます。ボードステータスとインターフェースステータスの両方のTLVがレポートメッセージで伝えられます（セクション6.4）。
Once the CP collects the interface status of a UP, it will activate/deactivate/modify the BAS functions on specified interfaces through the Update_Request and Update_Response message exchanges (Section 6.2), carrying the BAS Function TLV (Section 7.7).
CPがUPのインターフェースステータスを収集すると、Update_RequestおよびUpdate_Responseメッセージ交換（セクション6.2）を介して、指定されたインターフェースのBAS機能をアクティブ化/非アクティブ化/変更し、BAS機能TLV（セクション7.7）を伝達します。
UP CP
| Update BAS Function |
| Request |
|<-----on UP via Ci-------|
| |
| Update BAS Function |
| Response |
|------on UP via Ci------>|
| |
Figure 6: Update BAS Function
図6：BAS機能の更新
The CP will allocate one or more address blocks to a UP. Each address block contains a series of IP addresses. Those IP addresses will be assigned to subscribers who are dialing up to the UP. To enable the other nodes in the network to learn how to reach the subscribers, the CP needs to install the routes on the UP and notify the UP to advertise the routes to the network.
CPは1つ以上のアドレスブロックをUPに割り当てます。各アドレスブロックには、一連のIPアドレスが含まれています。これらのIPアドレスは、UPにダイヤルアップする加入者に割り当てられます。ネットワーク内の他のノードが加入者に到達する方法を学習できるようにするには、CPがルートをUPにインストールし、UPにネットワークへのルートをアドバタイズするよう通知する必要があります。
UP CP
| Subscriber network route|
| update request |
|<------- via Ci----------|
| |
| Subscriber network route|
| update response |
|-------- via Ci--------->|
| |
Figure 7: Update Network Routing
図7：ネットワークルーティングの更新
The Update_Request and Update_Response message exchanges, carrying the IPv4/IPv6 Routing TLVs (Section 7.8), update the subscriber's network routing information.
IPv4 / IPv6ルーティングTLV（セクション7.8）を伝送するUpdate_RequestおよびUpdate_Responseメッセージ交換は、加入者のネットワークルーティング情報を更新します。
The following sequences (Figure 8) describe the procedures related to CGN address management. Three independent procedures are defined: one each for CGN address allocation request/response, CGN address renewal request/response, and CGN address release request/response.
次のシーケンス（図8）は、CGNアドレス管理に関連する手順を示しています。 3つの独立した手順が定義されています。CGNアドレス割り当て要求/応答、CGNアドレス更新要求/応答、およびCGNアドレス解放要求/応答に対して1つずつです。
CGN address allocation/renew/release procedures are designed for the case where the CGN function is running on the UP. The UP has to map the subscriber private IP addresses to public IP addresses, and such mapping is performed by the UP locally when a subscriber dials up. That means the UP has to ask for public IPv4 address blocks for CGN subscribers from the CP.
CGNアドレスの割り当て/更新/解放手順は、CGN機能がUPで実行されている場合のために設計されています。 UPはサブスクライバーのプライベートIPアドレスをパブリックIPアドレスにマップする必要があり、そのようなマッピングはサブスクライバーがダイヤルアップするときにローカルでUPによって実行されます。つまり、UPはCPからCGNサブスクライバーのパブリックIPv4アドレスブロックを要求する必要があります。
In addition, when a public IP address is allocated to a UP, there will be a lease time (e.g., one day). Before the lease time expires, the UP can ask for renewal of the IP address lease from the CP. It is achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack messages.
また、パブリックIPアドレスがUPに割り当てられると、リース期間（1日など）が発生します。リース時間が期限切れになる前に、UPはCPからIPアドレスのリースの更新を要求できます。これは、Addr_Renew_ReqおよびAddr_Renew_Ackメッセージの交換によって実現されます。
If the public IP address will not be used anymore, the UP SHOULD release the address by sending an Addr_Release_Req message to the CP.
パブリックIPアドレスが使用されなくなる場合、UPはCPにAddr_Release_Reqメッセージを送信してアドレスを解放する必要があります（SHOULD）。
If the CP wishes to withdraw addresses that it has previously leased to a UP, it uses the same procedures as above. The Oper code (see Section 7.1) in the IPv4/IPv6 Routing TLV (see Section 7.8) determines whether the request is an update or withdraw.
CPが以前にUPにリースしていたアドレスを撤回したい場合は、上記と同じ手順を使用します。 IPv4 / IPv6ルーティングTLV（セクション7.8を参照）のOperコード（セクション7.1を参照）は、要求が更新か撤回かを決定します。
The relevant messages are defined in Section 6.5.
関連メッセージはセクション6.5で定義されています。
UP CP
| CGN Address Allocation |
| Request |
1.1|-------- via Ci--------->|
| CGN Address Allocation |
| Response |
1.2|<------- via Ci----------|
| |
| CGN Address Renew |
| Request |
2.1|-------- via Ci--------->|
| CGN Address Renew |
| Response |
2.2|<------- via Ci----------|
| |
| CGN Address Release |
| Request |
3.1|-------- via Ci--------->|
| CGN Address Release |
| Response |
3.3|<------- via Ci----------|
| |
Figure 8: CGN Public IP Address Allocation
図8：CGNパブリックIPアドレスの割り当て
For a CU-separated BNG, the UP will continue to function using the state that has been installed in it even if the CP fails or the session between the UP and CP fails.
CUで区切られたBNGの場合、CPが失敗したり、UPとCPの間のセッションが失敗したりしても、UPはインストールされている状態を使用して機能し続けます。
Under some circumstances, it is necessary to synchronize state between the CP and UP, for example, if a CP fails and the UP is switched to a different CP.
状況によっては、CPとUPの間で状態を同期する必要があります。たとえば、CPに障害が発生し、UPが別のCPに切り替えられた場合などです。
Synchronization includes two directions. One direction is from UP to CP; in that case, the synchronization information is mainly about the board/interface status of the UP. The other direction is from CP to UP; in that case, the subscriber sessions, subscriber network routes, L2TP tunnels, etc., will be synchronized to the UP.
同期には2つの方向があります。 1つの方向は、UPからCPです。その場合、同期情報は主にUPのボード/インターフェースのステータスに関するものです。もう1つの方向はCPからUPです。その場合、加入者セッション、加入者ネットワークルート、L2TPトンネルなどがUPに同期されます。
The synchronization is triggered by a Sync_Request message, to which the receiver will (1) reply with a Sync_Begin message to notify the requester that synchronization will begin and (2) then start the synchronization using the Sync_Data message. When synchronization finishes, a Sync_End message will be sent.
同期はSync_Requestメッセージによってトリガーされ、受信者は（1）Sync_Beginメッセージで応答してリクエスターに同期の開始を通知し、（2）次にSync_Dataメッセージを使用して同期を開始します。同期が完了すると、Sync_Endメッセージが送信されます。
Figure 9 shows the process of data synchronization between a UP and a CP.
図9は、UPとCP間のデータ同期のプロセスを示しています。
UP CP
| Synchronization Request |
|<------- via Ci----------|
| |
| Synchronization Begin |
|-------- via Ci--------->|
| |
| Board/Interface Report |
|-------- via Ci--------->|
| |
| Synchronization End |
|-------- via Ci--------->|
| |
1) Synchronization from UP to CP
UP CP
| Synchronization Request |
|-------- via Ci--------->|
| |
| Synchronization Begin |
|<-------- via Ci---------|
| |
| Synchronizes |
|Subscriber Session States|
| Network Route Entries |
|<------- via Ci----------|
| |
| Synchronization End |
|<-------- via Ci---------|
| |
2) Synchronization from CP to UP
Figure 9: Data Synchronization
図9：データの同期
A subscriber session consists of a set of forwarding states, policies, and security rules that are applied to the subscriber. It is used for forwarding subscriber traffic in a UP. To initialize a session on a UP, a collection of hardware resources (e.g., NP, TCAM, etc.) has to be allocated to a session on a UP as part of its initiation.
サブスクライバーセッションは、サブスクライバーに適用される転送状態、ポリシー、およびセキュリティルールのセットで構成されます。 UPで加入者トラフィックを転送するために使用されます。 UP上のセッションを初期化するには、ハードウェアリソース（NP、TCAMなど）のコレクションを、その開始の一部としてUP上のセッションに割り当てる必要があります。
Procedures related to subscriber sessions include subscriber session creation, update, deletion, and statistics reporting. The following subsections give a high-level view of the procedures.
サブスクライバーセッションに関連する手順には、サブスクライバーセッションの作成、更新、削除、および統計レポートが含まれます。次のサブセクションでは、手順の概要を説明します。
The sequence below (Figure 10) describes the DHCP IPv4 dial-up process. It is an example that shows how a subscriber session is created. (An example for IPv6 appears in Section 5.1.2.)
以下のシーケンス（図10）は、DHCP IPv4ダイヤルアッププロセスを説明しています。これは、加入者セッションがどのように作成されるかを示す例です。 （IPv6の例はセクション5.1.2にあります。）
RG UP CP AAA
| Online Request| | |
1|-------------->| | |
| |Relay the Online Request| |
| 2|-----to CP via Si------>| Authentication|
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | Accounting |
| | 6|<------------->|
| | Send Online Response | |
| 7|<----to UP via Si-------| |
| | | |
|Online Response| | |
8|<--------------| | |
| | | |
Figure 10: Creating a Subscriber Session
図10：サブスクライバーセッションの作成
The request starts from an Online Request message (step 1) from the RG (for example, a DHCP Discovery packet). When the UP receives the Online Request from the RG, it will tunnel the Online Request to the CP through the Si (step 2). A tunneling technology implements the Si.
要求は、RGからのオンライン要求メッセージ（手順1）（たとえば、DHCP検出パケット）から始まります。 UPがRGからオンライン要求を受信すると、オンライン要求をSi経由でCPにトンネルします（ステップ2）。トンネリング技術はSiを実装します。
When the CP receives the Online Request from the UP, it will send an authentication request to the AAA server to authenticate and authorize the subscriber (step 3). When a positive reply is received from the AAA server, the CP starts to create a subscriber session for the request. Relevant resources (e.g., IP address, bandwidth, etc.) will be allocated to the subscriber. Policies and security rules will be generated for the subscriber. Then the CP sends a request to create a session to the UP through the Ci (step 4), and a response is expected from the UP to confirm the creation (step 5).
CPがUPからオンライン要求を受信すると、AAAサーバーに認証要求を送信して、加入者を認証および承認します（ステップ3）。 AAAサーバーから肯定応答が受信されると、CPは要求のサブスクライバーセッションの作成を開始します。関連リソース（IPアドレス、帯域幅など）がサブスクライバーに割り当てられます。サブスクライバー用のポリシーとセキュリティルールが生成されます。次に、CPはCiを介してセッションを作成する要求をUPに送信し（ステップ4）、作成を確認する応答がUPから期待されます（ステップ5）。
Finally, the CP will notify the AAA server to start accounting (step 6). At the same time, an Online Response message (for example, a DHCP Ack packet) will be sent to the UP through the Si (step 7). The UP will then forward the Online Response to the RG (step 8).
最後に、CPはAAAサーバーにアカウンティングの開始を通知します（ステップ6）。同時に、オンライン応答メッセージ（たとえば、DHCP Ackパケット）がSiを介してUPに送信されます（ステップ7）。その後、UPはオンライン応答をRGに転送します（ステップ8）。
That completes the subscriber activation process.
これで、加入者のアクティベーションプロセスが完了します。
The following numbered sequence (Figure 11) shows the process of updating the subscriber session.
次の番号のシーケンス（図11）は、サブスクライバーセッションの更新プロセスを示しています。
UP CP AAA
| | CoA Request |
| 1|<--------------|
| Session Update Request | |
2|<--------via Ci---------| |
| | |
| Session Update Response| |
3|---------via Ci-------->| |
| | CoA Response |
| 4|-------------->|
| | |
Figure 11: Updating a Subscriber Session
図11：サブスクライバーセッションの更新
When a subscriber session has been created on a UP, there may be requirements to update the session with new parameters (e.g., bandwidth, QoS, policies, etc.).
加入者セッションがUPで作成された場合、セッションを新しいパラメーター（帯域幅、QoS、ポリシーなど）で更新する必要がある場合があります。
This procedure is triggered by a Change of Authorization (CoA) request message sent by the AAA server. The CP will update the session on the UP according to the new parameters through the Ci.
この手順は、AAAサーバーから送信されたChange of Authorization（CoA）要求メッセージによってトリガーされます。 CPは、Ciを介した新しいパラメーターに従って、UPのセッションを更新します。
The call flow below shows how S-CUSP deals with a subscriber Offline Request.
以下のコールフローは、S-CUSPがサブスクライバーのオフライン要求を処理する方法を示しています。
RG UP CP
|Offline Request | |
1|--------------->| |
| | Relay the Offline |
| | Request |
| 2|------to CP via Si----->|
| | |
| | Send the Offline |
| | Response |
| 3|<-----to UP via Si------|
|Offline Response| |
4|<---------------| |
| | Session Delete |
| | Request |
| |<--------via Ci---------|
| | Session Delete |
| | Response |
| |---------via Ci-------->|
| | |
Figure 12: Deleting a Subscriber Session
図12：サブスクライバーセッションの削除
Similar to the session creation process, when a UP receives an Offline Request from an RG, it will tunnel the request to a CP through the Si.
セッション作成プロセスと同様に、UPはRGからオフライン要求を受信すると、要求をSi経由でCPにトンネルします。
When the CP receives the Offline Request, it will withdraw/release the resources (e.g., IP address, bandwidth) that have been allocated to the subscriber. It then sends a reply to the UP through the Si, and the UP will forward the reply to the RG. At the same time, it will delete all the status of the session on the UP through the Ci.
CPがオフライン要求を受信すると、サブスクライバーに割り当てられているリソース（IPアドレス、帯域幅など）を撤回/解放します。次に、Siを介してUPに応答を送信し、UPは応答をRGに転送します。同時に、Ciを介してUPのセッションのステータスをすべて削除します。
UP CP
| Statistic/Detect Report|
|---------via Ci-------->|
| |
Figure 13: Events Report
図13：イベントレポート
When a session is created on a UP, the UP will periodically report statistics information and subscriber detection results of the session to the CP.
UPでセッションが作成されると、UPは定期的にセッションの統計情報と加入者検出結果をCPに報告します。
The subsections below give an overview of various "dial-up" interactions over the Si followed by an overview of the setting of information in the UP by the CP using S-CUSP over the Ci.
以下のサブセクションでは、Siを介したS-CUSPを使用したCPによるUPでの情報の設定の概要が続く、Siを介したさまざまな「ダイヤルアップ」相互作用の概要を示します。
S-CUSP messages are described in this document using Routing Backus Naur Form (RBNF) as defined in [RFC5511].
このドキュメントでは、[RFC5511]で定義されているRouting Backus Naur Form（RBNF）を使用してS-CUSPメッセージを説明しています。
The following sequence (Figure 14) shows detailed procedures for DHCPv4 access.
次のシーケンス（図14）は、DHCPv4アクセスの詳細な手順を示しています。
RG UP CP AAA
| DHCP Discovery| | |
1|-------------->| | |
| |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Send the DHCP Offer | |
| 4|<----to UP via Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request | |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| | | |
| DHCP ACK | | |
12|<--------------| | |
| | | |
Figure 14: DHCPv4 Access
図14：DHCPv4アクセス
S-CUSP implements steps 8 and 9.
S-CUSPはステップ8と9を実装します。
After a subscriber is authenticated and authorized by the AAA server, the CP creates a new subscriber session on the UP. This is achieved by sending an Update_Request message to the UP.
サブスクライバーがAAAサーバーによって認証および承認された後、CPはUPに新しいサブスクライバーセッションを作成します。これは、Update_RequestメッセージをUPに送信することで実現されます。
The format of the Update_Request message is shown as follows using RBNF:
Update_Requestメッセージのフォーマットは、RBNFを使用して次のように表示されます。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message. The format of the Update_Response message is as follows:
UPはUpdate_Responseメッセージで応答します。 Update_Responseメッセージの形式は次のとおりです。
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
The following sequence (Figure 15) shows detailed procedures for DHCPv6 access.
次のシーケンス（図15）は、DHCPv6アクセスの詳細な手順を示しています。
RG UP CP AAA
| Solicit | | |
1|-------------->| | |
| | Relay the Solicit | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Send the Advertise | |
| 4|<----to UP via Si-------| |
| Advertise | | |
5|<--------------| | |
| | | |
| Request | | |
6|-------------->| | |
| | Relay the Request | |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci-------->| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send Reply | |
| 11|<----to UP via Si-------| |
| Reply | | |
12|<--------------| | |
| | | |
Figure 15: DHCPv6 Access
図15：DHCPv6アクセス
Steps 1-7 are a standard DHCP IPv6 access process. The subscriber creation is triggered by a DHCP IPv6 request message. When this message is received, it means that the subscriber has passed the AAA authentication and authorization. Then the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP (step 8).
手順1〜7は、標準のDHCP IPv6アクセスプロセスです。サブスクライバーの作成は、DHCP IPv6要求メッセージによってトリガーされます。このメッセージが受信された場合、サブスクライバがAAA認証および許可に合格したことを意味します。次に、CPはUPにサブスクライバーセッションを作成します。これは、Update_RequestメッセージをUPに送信することで実現されます（ステップ8）。
The format of the Update_Request message is as follows:
Update_Requestメッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (step 9). The format of the Update_Response message is as follows:
UPはUpdate_Responseメッセージで応答します（ステップ9）。 Update_Responseメッセージの形式は次のとおりです。
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
The following flow (Figure 16) shows the IPv6 SLAAC access process.
次のフロー（図16）は、IPv6 SLAACアクセスプロセスを示しています。
RG UP CP AAA
| RS | | |
1|-------------->| | |
| | Relay the Router | |
| | Solicit (RS) | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send Router Advertise | |
| | (RA) | |
| 6|<----to UP via Si-------| |
| RA | | |
7|<--------------| | |
| | | |
| NS | | |
8|-------------->| | |
| | Relay the Neighbor | |
| | Solicit (NS) | |
| 9|-----to CP via Si------>| |
| | | Accounting |
| | 10|<------------->|
| | Send a Neighbor | |
| | Advertise (NA) | |
| 11|<----to UP via Si-------| |
| NA | | |
12|<--------------| | |
| | | |
Figure 16: IPv6 SLAAC Access
図16：IPv6 SLAACアクセス
It starts with a Router Solicit (RS) request from an RG that is tunneled to the CP by the UP. After the AAA authentication and authorization, the CP will create a subscriber session on the UP.
これは、UPによってCPにトンネルされるRGからのルーター要請（RS）要求で始まります。 AAA認証および許可の後、CPはUPで加入者セッションを作成します。
This is achieved by sending an Update_Request message to the UP (step 4).
これは、Update_RequestメッセージをUPに送信することで実現されます（ステップ4）。
The format of the Update_Request message is as follows:
Update_Requestメッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (step 5). The format of the Update_Response message is as follows:
UPはUpdate_Responseメッセージで応答します（ステップ5）。 Update_Responseメッセージの形式は次のとおりです。
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
The following call flow (Figure 17) shows the DHCP IPv6 and SLAAC access process.
次のコールフロー（図17）は、DHCP IPv6およびSLAACアクセスプロセスを示しています。
RG UP CP AAA
| RS | | |
1|-------------->| | |
| | Relay the RS | |
| 2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| 5|---------via Ci-------->| |
| | | |
| | Send RA | |
| 6|<----to UP via Si-------| |
| RA | | |
7|<--------------| | |
| | | |
|DHCPv6 Solicit | | |
8|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 9|-----to CP via Si------>| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 10|<--------via Ci---------| |
| | | |
| | Update Subscriber | |
| | Session Response | |
| 11|---------via Ci-------->| |
| | | Accounting |
| | 12|<------------->|
| | Send DHCPv6 Reply | |
| 13|<----to UP via Si-------| |
| | | |
| DHCPv6 Reply | | |
14|<--------------| | |
| | | |
Figure 17: DHCPv6 and SLAAC Access
図17：DHCPv6とSLAACアクセス
When a subscriber passes AAA authentication, the CP will create a subscriber session on the UP. This is achieved by sending an Update_Request message to the UP (step 4).
加入者がAAA認証に合格すると、CPはUPに加入者セッションを作成します。これは、Update_RequestメッセージをUPに送信することで実現されます（ステップ4）。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (step 5). The format of the Update_Response is as follows:
UPはUpdate_Responseメッセージで応答します（ステップ5）。 Update_Responseの形式は次のとおりです。
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
After receiving a DHCPv6 Solicit, the CP will update the subscriber session by sending an Update_Request message with new parameters to the UP (step 10).
DHCPv6 Solicitを受信した後、CPは新しいパラメータを含むUpdate_RequestメッセージをUPに送信することにより、加入者セッションを更新します（ステップ10）。
The format of the Update_Request message is as follows:
Update_Requestメッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
The UP will reply with an Update_Response message (step 11). The format of the Update_Response is as follows:
UPはUpdate_Responseメッセージで応答します（ステップ11）。 Update_Responseの形式は次のとおりです。
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
The following sequence (Figure 18) is a combination of DHCP IPv4 and DHCP IPv6 access processes.
次のシーケンス（図18）は、DHCP IPv4およびDHCP IPv6アクセスプロセスの組み合わせです。
RG UP CP AAA
| DHCP Discovery| | |
1|-------------->| | |
| |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA |
| | | Req/Resp |
| | 3|<------------->|
| | Send the DHCP Offer | |
| 4|<----to UP via Si-------| |
| DHCP Offer | | |
5|<--------------| | |
| DHCP Request | | |
6|-------------->| | |
| | Relay the DHCP Request| |
| 7|-----to CP via Si------>| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci-------->| |
| | Create Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| | Send DHCP ACK | |
| 11|<----to UP via Si-------| |
| DHCP ACK | | |
12|<--------------| | |
| RS | | |
13|-------------->| | |
| | Relay the RS | |
| 14|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 15|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 16|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 17|---------via Ci-------->| |
| | | |
| | Send the RA | |
| 18|<----to UP via Si-------| |
| RA | | |
19|<--------------| | |
|DHCPv6 Solicit | | |
20|-------------->| | |
| | Relay DHCPv6 Solicit | |
| 21|-----to CP via Si------>| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 22|<--------via Ci---------| |
| | Update Subscriber | |
| | Session Response | |
| 23|---------via Ci-------->| |
| | | Accounting |
| | 24|<------------->|
| | Send DHCPv6 Reply | |
| 25|<----to UP via Si-------| |
| DHCPv6 Reply | | |
26|<--------------| | |
| | | |
Figure 18: DHCP Dual-Stack Access
図18：DHCPデュアルスタックアクセス
The DHCP dual-stack access includes three sets of Update_Request/ Update_Response exchanges to create/update a DHCPv4/v6 subscriber session.
DHCPデュアルスタックアクセスには、DHCPv4 / v6サブスクライバーセッションを作成/更新するためのUpdate_Request / Update_Response交換の3つのセットが含まれています。
(1) Create a DHCPv4 session (steps 8 and 9):
（1）DHCPv4セッションを作成します（ステップ8および9）：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
(2) Create a DHCPv6 session (steps 16 and 17):
（2）DHCPv6セッションを作成します（ステップ16および17）：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
(3) Update DHCPv6 session (steps 22 and 23):
（3）DHCPv6セッションを更新します（ステップ22および23）：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
L2 static subscriber access processes are as follows:
L2静的加入者アクセスプロセスは次のとおりです。
RG UP CP AAA
| | Static Subscriber | |
| | Detection Req. | |
| 1|<-----to UP via Ci------| |
| | Static Subscriber | |
| | Detection Rep. | |
| 2|------to UP via Ci----->| |
| ARP/ND(REQ) | | |
3.1|<--------------| | |
| ARP/ND(ACK) | | |
3.2|-------------->| | |
| | Relay the ARP/ND | |
| 3.3|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 3.4|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 3.5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 3.6|---------via Ci-------->| |
| ARP/ND(REQ) | | |
4.1|-------------->| | |
| | Relay the ARP/ND | |
| 4.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 4.3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 4.4|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 4.5|---------via Ci-------->| |
| ARP/ND(ACK) | | |
4.6|<--------------| | |
| IP Traffic | | |
5.1|-------------->| | |
| | Relay the IP Traffic | |
| 5.2|-----to CP via Si------>| AAA |
| | | Req/Rep |
| | 5.3|<------------->|
| | Create Subscriber | |
| | Session Request | |
| 5.4|<--------via Ci-------->| |
| | Create Subscriber | |
| | Session Response | |
| 5.5|---------via Ci-------->| |
| ARP/ND(REQ) | | |
5.6|<--------------| | |
| ARP/ND(ACK) | | |
5.7|-------------->| | |
| | | |
Figure 19: L2 Static Subscriber Access
図19：L2静的サブスクライバーアクセス
For L2 static subscriber access, the process starts with a CP installing a static subscriber detection list on a UP. The list determines which subscribers will be detected. That is implemented by exchanging Update_Request and Update_Response messages between CP and UP. The formats of the messages are as follows:
L2静的サブスクライバーアクセスの場合、プロセスはCPがUPに静的サブスクライバー検出リストをインストールするところから始まります。リストは、検出されるサブスクライバーを決定します。これは、CPとUPの間でUpdate_RequestメッセージとUpdate_Responseメッセージを交換することによって実装されます。メッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<IPv4 Static Subscriber Detect TLVs>
<IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
For L2 static subscriber access, there are three ways to trigger the access process:
L2静的サブスクライバーアクセスの場合、アクセスプロセスをトリガーする方法は3つあります。
(1) Triggered by UP (steps 3.1-3.6): This assumes that the UP knows the IP address, the access interface, and the VLAN of the RG. The UP will actively trigger the access flow by sending an ARP/ ND packet to the RG. If the RG is online, it will reply with an ARP/ND to the UP. The UP will tunnel the ARP/ND to the CP through the Si. The CP then triggers the authentication process. If the authentication result is positive, the CP will create a corresponding subscriber session on the UP.
（1）UPによってトリガー（ステップ3.1〜3.6）：これは、UPがRGのIPアドレス、アクセスインターフェイス、およびVLANを知っていることを前提としています。 UPは、ARP / NDパケットをRGに送信することにより、アクセスフローをアクティブにトリガーします。 RGがオンラインの場合、ARP / NDでUPに応答します。 UPはARP / NDをSi経由でCPにトンネルします。次に、CPは認証プロセスをトリガーします。認証結果が正の場合、CPは対応するサブスクライバーセッションをUPに作成します。
(2) Triggered by RG ARP/ND (steps 4.1-4.6): Most of the process is the same as option 1 (triggered by UP). The difference is that the RG will actively send the ARP/ND to trigger the process.
（2）RG ARP / NDによってトリガー（ステップ4.1〜4.6）：ほとんどのプロセスは、オプション1（UPによってトリガー）と同じです。違いは、RGがARP / NDをアクティブに送信してプロセスをトリガーすることです。
(3) Triggered by RG IP traffic (steps 5.1-5.7): This is for the case where the RG has the ARP/ND information, but the subscriber session on the UP is lost (e.g., due to failure on the UP or the UP restarting). That means the RG may keep sending IP packets to the UP. The packets will trigger the UP to start a new access process.
（3）RG IPトラフィックによってトリガーされます（ステップ5.1〜5.7）：これは、RGにARP / ND情報が含まれているが、UPのサブスクライバーセッションが失われた場合（たとえば、UPまたはUP再起動）。つまり、RGはIPパケットをUPに送信し続ける可能性があります。パケットはUPをトリガーして新しいアクセスプロセスを開始します。
From a subscriber session point of view, the procedures and the message formats for the three cases above are the same, as follows.
サブスクライバセッションの観点から見ると、上記の3つのケースの手順とメッセージフォーマットは次のように同じです。
IPv4 Case:
IPv4ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
IPv6ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Figure 20 shows the IPv4 PPPoE access call flow.
図20は、IPv4 PPPoEアクセスコールフローを示しています。
RG UP CP AAA
| PPPoE Disc | PPPoE Disc | |
1|<------------->|<---------via Si------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| | | |
Figure 20: IPv4 PPPoE Access
図20：IPv4 PPPoEアクセス
In the above sequence, steps 1-4 are the standard PPPoE call flow. The UP is responsible for redirecting the PPPoE control packets to the CP or RG. The PPPoE control packets are transmitted between the CP and UP through the Si.
上記のシーケンスで、ステップ1〜4は標準のPPPoEコールフローです。 UPは、PPPoE制御パケットをCPまたはRGにリダイレクトします。 PPPoE制御パケットは、CPとUPの間でSiを介して送信されます。
After the PPPoE call flow, if the subscriber passed the AAA authentication and authorization, the CP will create a corresponding session on the UP through the Ci. The formats of the messages are as follows:
PPPoEコールフローの後、加入者がAAA認証および許可に合格した場合、CPは、Ciを介してUPで対応するセッションを作成します。メッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
Figure 21 describes the IPv6 PPPoE access call flow.
図21は、IPv6 PPPoEアクセスコールフローを示しています。
RG UP CP AAA
| PPPoE Disc | PPPoE Disc | |
1|<------------->|<--------via Si-------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IP6CP | PPP IP6CP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create Subscriber | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
7|<------------->|<---------via Si------->| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | Update Subscriber | |
| | Session Response | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | 10|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
7'|<------------->|<---------via Si------->| |
| | | |
| | Update Subscriber | |
| | Session Request | |
| 8'|<---------via Ci--------| |
| | Update Subscriber | |
| | Session Response | |
| 9'|---------via Ci-------->| |
| | | Accounting |
| | 10'|<------------->|
| | | |
Figure 21: IPv6 PPPoE Access
図21：IPv6 PPPoEアクセス
From the above sequence, steps 1-4 are the standard PPPoE call flow. The UP is responsible for redirecting the PPPoE control packets to the CP or RG. The PPPoE control packets are transmitted between the CP and UP through the Si.
上記のシーケンスから、ステップ1〜4は標準のPPPoEコールフローです。 UPは、PPPoE制御パケットをCPまたはRGにリダイレクトします。 PPPoE制御パケットは、CPとUPの間でSiを介して送信されます。
After the PPPoE call flow, if the subscriber passed the AAA authentication and authorization, the CP will create a corresponding session on the UP through the Ci. The formats of the messages are as follows:
PPPoEコールフローの後、加入者がAAA認証および許可に合格した場合、CPは、Ciを介してUPで対応するセッションを作成します。メッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Then, the RG will initialize an ND/DHCPv6 negotiation process with the CP (see steps 7 and 7'); after that, it will trigger an update (steps 8-9 and 8'-9') to the subscriber session. The formats of the update messages are as follows:
次に、RGは、CPとのND / DHCPv6ネゴシエーションプロセスを初期化します（ステップ7および7 'を参照）。その後、サブスクライバーセッションの更新（ステップ8-9および8'-9 '）がトリガーされます。更新メッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Figure 22 shows a combination of IPv4 and IPv6 PPPoE access call flows.
図22は、IPv4とIPv6のPPPoEアクセスコールフローの組み合わせを示しています。
RG UP CP AAA
|PPPoE Discovery| PPPoE Discovery | |
1|<------------->|<---------via Si------->| |
| | | |
| PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| |
| | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->|
| | | |
| PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| |
| | | |
| | Create v4 Subscriber | |
| | Session Request | |
| 5|<--------via Ci---------| |
| | Create v4 Subscriber | |
| | Session Response | |
| 6|---------via Ci-------->| |
| | | Accounting |
| | 7|<------------->|
| PPP IP6CP | PPP IP6CP | |
4'|<------------->|<---------via Si------->| |
| | | |
| | Create V6 Subscriber | |
| | Session Request | |
| 5'|<--------via Ci---------| |
| | Create v6 Subscriber | |
| | Session Response | |
| 6'|---------via Ci-------->| |
| | | |
| ND Negotiation| ND Negotiation | |
8|<------------->|<---------via Si------->| |
| | | |
| | Update v6 Subscriber | |
| | Session Request | |
| 9|<---------via Ci--------| |
| | Update v6 Subscriber | |
| | Session Response | |
| 10|---------via Ci-------->| |
| | | Accounting |
| | 7'|<------------->|
| DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | |
8'|<------------->|<---------via Si------->| |
| | | |
| | Update v6 Subscriber | |
| | Session Request | |
| 9'|<--------via Ci---------| |
| | Update v6 Subscriber | |
| | Session Response | |
| 10'|---------via Ci-------->| |
| | | Accounting |
| | 7"|<------------->|
| | | |
Figure 22: PPPoE Dual-Stack Access
図22：PPPoEデュアルスタックアクセス
PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE access. The process is as above. The formats of the messages are as follows:
PPPoEデュアルスタックは、IPv4 PPPoEとIPv6 PPPoEアクセスの組み合わせです。プロセスは上記のとおりです。メッセージの形式は次のとおりです。
(1) Create an IPv4 PPPoE subscriber session (steps 5-6):
（1）IPv4 PPPoEサブスクライバーセッションを作成します（手順5〜6）：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
(2) Create an IPv6 PPPoE subscriber session (steps 5'-6'):
（2）IPv6 PPPoEサブスクライバーセッションを作成します（ステップ5'-6 '）：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
(3) Update the IPv6 PPPoE subscriber session (steps 9-10 and 9'- 10'):
（3）IPv6 PPPoEサブスクライバーセッションを更新します（ステップ9-10および9'-10 '）：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Figure 23 shows the WLAN access call flow.
図23は、WLANアクセスのコールフローを示しています。
RG UP CP AAA Web Server
| DHCP | | | |
| Discovery | | | |
1|------------>| | | |
| | DHCP Discovery | | |
| 2|-----via Si---->| AAA | |
| | DHCP Offer |<-------->| |
| 3|<----via Si-----| | |
| DHCP Offer | | | |
4|<------------| | | |
| DHCP Request| | | |
5|------------>| | | |
| | DHCP Request | | |
| 6|-----via Si---->| | |
| | | | |
| | Create Session | | |
| | Request | | |
| 7|<----via Ci-----| | |
| | Create Session | | |
| | Response | | |
| 8|----via Ci----->| | |
| | | | |
| | DHCP ACK | | |
| 9|<----via Si-----| | |
| DHCP ACK | | | |
10|<------------| | | |
| | | | |
| Subscriber | | | |
| HTTP Traffic| | | |
11|------------>|--> | | |
| | | Web URL | | |
| Traffic | | Redirect | | |
| Redirection | | | | |
12|<------------|<-+ | | |
| |
13|-----------------Redirect to Web Server------------->|
| |
14|<----------------Push HTTP Log-in Page---------------|
| |
15|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 16|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 17|<-------->| |
| | | | |
| | Update Session | | |
| | Request | | |
| 18|<----via Ci-----| | |
| | Update Session | | |
| | Response | | |
| 19|-----via Ci---->| | |
| | | | |
Figure 23: WLAN Access
図23：WLANアクセス
WLAN access starts with the DHCP dial-up process (steps 1-6). After that, the CP will create a subscriber session on the UP (steps 7-8). The formats of the session creation messages are as follows:
WLANアクセスは、DHCPダイヤルアッププロセス（ステップ1〜6）から始まります。その後、CPはUPでサブスクライバーセッションを作成します（手順7〜8）。セッション作成メッセージの形式は次のとおりです。
IPv4 Case:
IPv4ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
IPv6ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
After step 10, the RG will be allocated an IP address, and its first HTTP packet will be redirected to a web server for subscriber authentication (steps 11-17). After the web authentication, if the result is positive, the CP will update the subscriber session by using the following message exchanges:
ステップ10の後、RGにはIPアドレスが割り当てられ、その最初のHTTPパケットは、加入者認証のためにWebサーバーにリダイレクトされます（ステップ11〜17）。 Web認証後、結果が正の場合、CPは次のメッセージ交換を使用してサブスクライバセッションを更新します。
IPv4 Case:
IPv4ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
IPv6ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
RG UP(LAC) CP(LAC) AAA LNS
| PPPoE | PPPoE | | |
| Discovery | Discovery | | |
1|<---------->|<---via Si--->| | |
| | | | |
| PPP LCP | PPP LCP | | |
2|<---------->|<---via Si--->| | |
| | | AAA | |
|PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| |
3|<---------->|<---via Si--->|<------>| |
| | | | |
| PPP IPCP | PPP IPCP | | |
4|<---------->|<---via Si--->| | |
| | | | |
| | L2TP Tunnel | | |
| | Negotiation | | |
| | SCCRQ/ | | |
| | SCCRP/ | | |
| | SCCCN | | |
| 5|<---via Si--->| | |
| | /\ |
| | || Forward |
| | \/ |
| |<-----------via Routing---------->|
| | |
| | L2TP Session | | |
| | Negotiation | | |
| | ICRQ/ | | |
| | ICRP/ | | |
| | ICCN | | |
| 6|<---via Si--->| | |
| | /\ |
| | || Forward |
| | \/ |
| |<-----------via Routing---------->|
| | |
| | Create | | |
| | Subscriber | | |
| | Session Req | | |
| 7|<---via Ci----| | |
| | Create | | |
| | Subscriber | | |
| | Session Rep | | |
| 8|----via Ci--->| | |
| | | | |
| |
| PAP/CHAP (Triggered by LNS) |
9|<-----------------via Routing----------------->|
| |
Figure 24: L2TP LAC Access
図24：L2TP LACアクセス
Steps 1-4 are a standard PPPoE access process. After that, the LAC-CP starts to negotiate an L2TP session and tunnel with the LNS. After the negotiation, the CP will create an L2TP LAC subscriber session on the UP through the following messages:
手順1〜4は、標準のPPPoEアクセスプロセスです。その後、LAC-CPはL2TPセッションのネゴシエーションを開始し、LNSとトンネルします。ネゴシエーション後、CPは次のメッセージを通じてUPでL2TP LACサブスクライバーセッションを作成します。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<L2TP-LAC Subscriber TLV>
<L2TP-LAC Tunnel TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
RG LAC UP(LNS) AAA CP(LNS)
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | L2TP Tunnel | L2TP Tunnel |
| | Negotiation | Negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP Session | L2TP Session |
| | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create Subscriber |
| | | Session Request |
| | 6|<-----via Ci-------|
| | | Create Subscriber |
| | | Session Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | |
| |
| PPP IPCP |
10|<--------------------------------------------->|
| |
| | | Update Subscriber |
| | | Session Request |
| | 11|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 12|------via Ci------>|
| | | |
Figure 25: L2TP LNS IPv4 Access
図25：L2TP LNS IPv4アクセス
In this case, the BNG is running as an LNS and separated into LNS-CP and LNS-UP. Steps 1-5 finish the normal L2TP dial-up process. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP. The format of the messages is as follows:
この場合、BNGはLNSとして実行され、LNS-CPとLNS-UPに分離されます。手順1〜5で、通常のL2TPダイヤルアッププロセスが完了します。 L2TPセッションとトンネルネゴシエーションが完了すると、LNS-CPはLNS-UP上にL2TP LNSサブスクライバーセッションを作成します。メッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
After that, the LNS-CP will trigger a AAA authentication. If the authentication result is positive, a PPP IP Control Protocol (IPCP) process will follow, and then the CP will update the session with the following message exchanges:
その後、LNS-CPはAAA認証をトリガーします。認証結果が正の場合、PPP IP制御プロトコル（IPCP）プロセスが続き、CPは次のメッセージ交換でセッションを更新します。
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
RG LAC UP(LNS) AAA CP(LNS)
| PPPoE | | | |
| Discovery | | | |
1|<---------->| | | |
| | | | |
| PPP LCP | | | |
2|<---------->| | |
| | AAA | |
|PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| |
| | |
| | L2TP Tunnel | L2TP Tunnel |
| | Negotiation | Negotiation |
| | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->|
| | | |
| | L2TP Session | L2TP Session |
| | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ |
| | ICCN | ICCN |
| 5|<------------>|<------via Si----->|
| | | |
| | | Create Subscriber |
| | | Session Request |
| | 6|<-----via Ci-------|
| | | Create Subscriber |
| | | Session Response |
| | 7|------via Ci------>|
| |
| PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->|
| |
| | | | AAA |
| | | | Req/Rep |
| | | 9|<-------->|
| | | | |
| |
| PPP IP6CP |
10|<--------------------------------------------->|
| |
| | | Update Subscriber |
| | | Session Request |
| | 11|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 12|------via Ci------>|
| | |
| ND Negotiation | ND Negotiation |
13|<------------------------->|<-----via Si------>|
| | |
| | | Update Subscriber |
| | | Session Request |
| | 14|<-----via Ci-------|
| | | Update Subscriber |
| | | Session Response |
| | 15|------via Ci------>|
| | | |
Figure 26: L2TP LNS IPv6 Access
図26：L2TP LNS IPv6アクセス
Steps 1-12 are the same as L2TP LNS IPv4 access. Steps 1-5 finish the normal L2TP dial-up process. When the L2TP session and tunnel negotiations are finished, the LNS-CP will create an L2TP LNS subscriber session on the LNS-UP. The format of the messages is as follows:
手順1〜12は、L2TP LNS IPv4アクセスと同じです。手順1〜5で、通常のL2TPダイヤルアッププロセスが完了します。 L2TPセッションとトンネルネゴシエーションが完了すると、LNS-CPはLNS-UP上にL2TP LNSサブスクライバーセッションを作成します。メッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
After that, the LNS-CP will trigger a AAA authentication. If the authentication result is positive, a PPP IP6CP process will follow, and then the CP will update the session with the following message exchanges:
その後、LNS-CPはAAA認証をトリガーします。認証結果が正の場合、PPP IP6CPプロセスが続き、CPは次のメッセージ交換でセッションを更新します。
<Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Then, an ND negotiation will be triggered by the RG. After the ND negotiation, the CP will update the session with the following message exchanges:
次に、RGによってNDネゴシエーションがトリガーされます。 NDネゴシエーションの後、CPは次のメッセージ交換でセッションを更新します。
<Update_Request Message> ::= <Common Header>
<L2TP-LAC Subscriber TLV>
<Basic Subscriber TLV>
<PPP Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
RG UP CP AAA
| | Public Address Block | |
| | Allocation Request | |
| 1|<--------via Ci-------->| |
| | Public Address Block | |
| | Allocation Reply | |
| 2|---------via Ci-------->| |
| Subscriber | | |
| Access Request| Subscriber | |
3|-------------->| Access Request | |
| 4|----------via Si------->| |
| | | AAA |
| | Subscriber | Req/Rep |
| Subscriber | Access Reply 5|<------------->|
| Access Reply 6|<---------via Si--------| |
7|<--------------| | |
| | Create Subscriber | |
| | Session Request | |
| 8|<--------via Ci---------| |
| | | |
| | Create Subscriber | |
| | Session Response | |
| | (with NAT information) | |
| 9|---------via Ci-------->| |
| | | Accounting |
| | | with source |
| | | information |
| | 10|<------------->|
| | | Public IP + |
| | | Port Range |
| | | to Private IP|
| | | Mapping |
| | | |
Figure 27: CGN Access
図27：CGNアクセス
The first steps allocate one or more CGN address blocks to the UP (steps 1-2). This is achieved by the following message exchanges between CP and UP:
最初のステップでは、1つ以上のCGNアドレスブロックをUPに割り当てます（ステップ1〜2）。これは、CPとUPの間の次のメッセージ交換によって実現されます。
<Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV>
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV>
Steps 3-9 show the general dial-up process in the case of CGN mode. The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in above sections.
手順3〜9は、CGNモードの場合の一般的なダイヤルアッププロセスを示しています。特定のプロセス（例：IPoE、PPPoE、L2TPなど）は、上記のセクションで定義されています。
If a subscriber is a CGN subscriber, once the subscriber session is created/updated, the UP will report the NAT information to the CP. This is achieved by carrying the Subscriber CGN Port Range TLV in the Update_Response message.
サブスクライバーがCGNサブスクライバーの場合、サブスクライバーセッションが作成/更新されると、UPはNAT情報をCPに報告します。これは、Update_ResponseメッセージでサブスクライバCGNポート範囲TLVを伝送することによって実現されます。
RG UP CP AAA Web Server
| User traffic| | | |
1|------------>| | | |
| | User traffic | | |
| 2|-----via Si---->| AAA | |
| | | Req/Rep | |
| | 3|<-------->| |
| | Create Session | | |
| | Request | | |
| 4|<----via Ci-----| | |
| | Create Session | | |
| | Response | | |
| 5|----via Ci----->| | |
| | | | |
| HTTP traffic| | | |
6|------------>| | | |
| | | | |
| Redirect to | | | |
| Web URL | | | |
7|<------------| | | |
| | | | |
| |
8|-----------------Redirected to Web Server----------->|
| |
9|<----------------Push HTTP Log-in Page---------------|
| |
10|-----------------User Authentication---------------->|
| |
| | | Portal Interchange |
| | 11|<-------------------->|
| | | |
| | | AAA | |
| | | Req/Rep | |
| | 12|<-------->| |
| | | | |
| | Update Session | | |
| | Request | | |
| 13|<----via Ci-----| | |
| | Update Session | | |
| | Response | | |
| 14|----via Ci----->| | |
| | | | |
Figure 28: Web Authentication-Based L3 Leased Line Access
図28：Web認証ベースのL3専用回線アクセス
In this case, IP traffic from the RG will trigger the CP to authenticate the RG by checking the source IP and the exchanges with the AAA server. Once the RG has passed the authentication, the CP will create a corresponding subscriber session on the UP through the following message exchanges:
この場合、RGからのIPトラフィックは、ソースIPおよびAAAサーバーとの交換をチェックすることにより、CPをトリガーしてRGを認証します。 RGが認証に合格すると、CPは次のメッセージ交換を介して、UPに対応するサブスクライバーセッションを作成します。
IPv4 Case:
IPv4ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
IPv6ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
Then, the HTTP traffic from the RG will be redirected to a web server to finish the web authentication. Once the web authentication is passed, the CP will trigger another AAA authentication. After the AAA authentication, the CP will update the session with the following message exchanges:
次に、RGからのHTTPトラフィックがWebサーバーにリダイレクトされ、Web認証が完了します。 Web認証に合格すると、CPは別のAAA認証をトリガーします。 AAA認証の後、CPは次のメッセージ交換でセッションを更新します。
IPv4 Case:
IPv4ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
IPv6ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
RG UP CP AAA
| | L3 access | |
| | control list | |
| 1|<----via Ci-----| |
| User | | |
| traffic | | |
2|------------>| | |
| | User traffic | |
| 3|-----via Si---->| |
| | | AAA |
| | | Req/Rep |
| | 4|<-------->|
| | | |
| | Create Session | |
| | Request | |
| 5|<----via Ci-----| |
| | Create Session | |
| | Response | |
| 6|----via Ci----->| |
| | | |
Figure 29: User Traffic Triggered L3 Leased Line Access
図29：ユーザートラフィックによってトリガーされるL3専用回線アクセス
In this case, the CP must install on the UP an access control list, which is used by the UP to determine whether or not an RG is legal. If the traffic is from a legal RG, it will be redirected to the CP though the Si. The CP will trigger a AAA interchange with the AAA server. After that, the CP will create a corresponding subscriber session on the UP with the following message exchanges:
この場合、CPはUPにアクセス制御リストをインストールする必要があります。アクセス制御リストは、RGが有効かどうかを判断するためにUPによって使用されます。トラフィックが正当なRGからのものである場合、Si経由でCPにリダイレクトされます。 CPは、AAAサーバーとのAAA交換をトリガーします。その後、CPは次のメッセージ交換でUPに対応するサブスクライバーセッションを作成します。
IPv4 Case:
IPv4ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case:
IPv6ケース：
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
[<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
RG UP CP AAA
| User Access | User Access | AAA |
| Request | Request | Req/Rep |
1|<----------->|<----via Si---->|<-------->|
| | | |
| | Create Session | |
| | Request | |
| 2|<----via Ci---->| |
| | | |
| | Create Session | |
| | Response | |
| 3|----via Ci----->| |
| | | |
| Multicast | | |
| negotiation | | |
4|<----------->| | |
| | | |
Figure 30: Multicast Access
図30：マルチキャストアクセス
Multicast access starts with a user access request from the RG. The request will be redirected to the CP by the Si. A follow-up AAA interchange between the CP and the AAA server will be triggered. After the authentication, the CP will create a multicast subscriber session on the UP through the following messages:
マルチキャストアクセスは、RGからのユーザーアクセス要求で始まります。リクエストはSiによってCPにリダイレクトされます。 CPとAAAサーバー間のフォローアップAAA交換がトリガーされます。認証後、CPは次のメッセージを介してUPでマルチキャストサブスクライバセッションを作成します。
IPv4 Case, there will be a Multicast-ProfileV4 sub-TLV present in the Subscriber Policy TLV:
IPv4の場合、サブスクライバーポリシーTLVにMulticast-ProfileV4サブTLVが存在します。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv4 Subscriber TLV>
<IPv4 Routing TLV>
<Subscriber Policy TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
[<Subscriber CGN Port Range TLV>]
IPv6 Case, there will be a Multicast-ProfileV6 sub-TLV present in the Subscriber Policy TLV:
IPv6の場合、サブスクライバポリシーTLVにMulticast-ProfileV6サブTLVが存在します。
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV>
<IPv6 Subscriber TLV>
<IPv6 Routing TLV>
<Subscriber Policy TLV>
<Update_Response Message> ::= <Common Header>
<Update Response TLV>
An S-CUSP message consists of a common header followed by a variable-length body consisting entirely of TLVs. Receiving an S-CUSP message with an unknown message type or missing mandatory TLV MUST trigger an Error message (see Section 6.7) or a Response message with an Error Information TLV (see Section 7.6).
S-CUSPメッセージは、共通ヘッダーで構成され、その後にTLVのみで構成される可変長の本体が続きます。不明なメッセージタイプまたは必須のTLVがないS-CUSPメッセージを受信すると、エラーメッセージ（セクション6.7を参照）またはエラー情報TLVを含む応答メッセージ（セクション7.6を参照）をトリガーする必要があります。
Conversely, if a TLV is optional, the TLV may or may not be present. Optional TLVs are indicated in the message formats shown in this document by being enclosed in square brackets.
逆に、TLVがオプションの場合、TLVが存在する場合と存在しない場合があります。オプションのTLVは、このドキュメントに示されているメッセージ形式では、角括弧で囲まれて示されています。
This section specifies the format of the common S-CUSP message header and lists the defined messages.
このセクションでは、一般的なS-CUSPメッセージヘッダーの形式を指定し、定義されたメッセージをリストします。
Network byte order is used for all multi-byte fields.
ネットワークバイトオーダーは、すべてのマルチバイトフィールドに使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Resv | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: S-CUSP Message Common Header
図31：S-CUSPメッセージの共通ヘッダー
Ver (4 bits): The major version of the protocol. This document specifies version 1. Different major versions of the protocol may have significantly different message structures and formats except that the Ver field will always be in the same place at the beginning of each message. A successful S-CUSP session depends on the CP and the UP both using the same major version of the protocol.
Ver（4ビット）：プロトコルのメジャーバージョン。このドキュメントはバージョン1を指定します。プロトコルのメジャーバージョンが異なると、メッセージ構造と形式が大幅に異なる場合があります。ただし、Verフィールドは各メッセージの先頭の常に同じ場所にあります。 S-CUSPセッションが成功するかどうかは、同じメジャーバージョンのプロトコルを使用するCPとUPの両方に依存します。
Resv (4 bits): Reserved. MUST be sent as zero and ignored on receipt.
Resv（4ビット）：予約済み。ゼロとして送信し、受信時に無視する必要があります。
Message-Type (8 bits): The set of message types specified in this document is listed in Section 8.1.
メッセージタイプ（8ビット）：このドキュメントで指定されているメッセージタイプのセットは、セクション8.1にリストされています。
Message-Length (16 bits): Total length of the S-CUSP message including the common header, expressed in number of bytes as an unsigned integer.
Message-Length（16ビット）：共通ヘッダーを含むS-CUSPメッセージの全長。符号なし整数としてバイト数で表されます。
Transaction-ID (16 bits): This field is used to identify requests. It is echoed back in any corresponding ACK/Response/Error message. It is RECOMMENDED that a monotonically increasing value be used in successive messages and that the value wraps back to zero after 0xFFFF. The content of this field is an opaque value that the receiver MUST NOT use for any purpose except to echo back in a corresponding response and, optionally, for logging.
Transaction-ID（16ビット）：このフィールドは、リクエストを識別するために使用されます。対応するACK / Response / Errorメッセージでエコーバックされます。連続するメッセージで単調に増加する値を使用し、値が0xFFFFの後にゼロに戻ることをお勧めします。このフィールドの内容は不透明な値であり、対応する応答でエコーバックすること、およびオプションでロギングを行うことを除いて、受信者がいかなる目的にも使用してはならない（MUST NOT）。
This document defines the following control messages:
このドキュメントでは、次の制御メッセージを定義しています。
+------+-----------------+------------------------------------+
| Type | Name | Notes and TLVs that can be carried |
+======+=================+====================================+
| 1 | Hello | Hello TLV, Keepalive TLV |
+------+-----------------+------------------------------------+
| 2 | Keepalive | A common header with the Keepalive |
| | | message type |
+------+-----------------+------------------------------------+
| 3 | Sync_Request | Synchronization request |
+------+-----------------+------------------------------------+
| 4 | Sync_Begin | Synchronization starts |
+------+-----------------+------------------------------------+
| 5 | Sync_Data | Synchronization data: TLVs |
| | | specified in Section 7 |
+------+-----------------+------------------------------------+
| 6 | Sync_End | End synchronization |
+------+-----------------+------------------------------------+
| 7 | Update_Request | TLVs specified in Sections 7.6-7.9 |
+------+-----------------+------------------------------------+
| 8 | Update_Response | TLVs specified in Sections 7.6-7.9 |
+------+-----------------+------------------------------------+
Table 2: Control Messages
表2：制御メッセージ
The Hello message is used for S-CUSP session establishment and version negotiation. The details of S-CUSP session establishment and version negotiation can be found in Section 4.1.1.
Helloメッセージは、S-CUSPセッションの確立とバージョンネゴシエーションに使用されます。 S-CUSPセッションの確立とバージョンネゴシエーションの詳細については、セクション4.1.1を参照してください。
The format of the Hello message is as follows:
Helloメッセージの形式は次のとおりです。
<Hello Message> ::= <Common Header>
<Hello TLV>
<Keepalive TLV>
[<Error Information TLV>]
The return code and negotiation result will be carried in the Error Information TLV. They are listed as follows:
戻りコードとネゴシエーションの結果は、エラー情報TLVで伝達されます。それらは次のとおりです。
0: Success. Version negotiation success.
0：成功。バージョンネゴシエーションが成功しました。
1: Failure. Malformed message received.
1：失敗。不正なメッセージを受け取りました。
2: TLV-Unknown. One or more of the TLVs was not understood.
2：TLV-不明。 1つ以上のTLVが理解されませんでした。
1001: Version-Mismatch. The version negotiation fails. The S-CUSP session establishment phase fails.
1001：バージョン不一致。バージョンのネゴシエーションは失敗します。 S-CUSPセッション確立フェーズは失敗します。
1002: Keepalive Error. The keepalive negotiation fails. The S-CUSP session establishment phase fails.
1002：キープアライブエラー。キープアライブネゴシエーションは失敗します。 S-CUSPセッション確立フェーズは失敗します。
1003: Timer Expires. The establishment timer expired. Session establishment phase fails.
1003：タイマーが切れます。確立タイマーが切れました。セッション確立フェーズが失敗しました。
Each end of an S-CUSP session periodically sends a Keepalive message. It is used to detect whether the peer end is still alive. The Keepalive procedures are defined in Section 4.1.2.
S-CUSPセッションの両端は、定期的にキープアライブメッセージを送信します。ピアエンドがまだ生きているかどうかを検出するために使用されます。キープアライブ手順はセクション4.1.2で定義されています。
The format of the Keepalive message is as follows:
キープアライブメッセージの形式は次のとおりです。
<Keepalive Message> ::= <Common Header>
The Sync_Request message is used to request synchronization from an S-CUSP peer. Both CP and UP can request their peer to synchronize data.
Sync_Requestメッセージは、S-CUSPピアからの同期を要求するために使用されます。 CPとUPはどちらも、データを同期するようにピアに要求できます。
The format of the Sync_Request message is as follows:
Sync_Requestメッセージの形式は次のとおりです。
<Sync_Request Message> ::= <Common Header>
A Sync_Request message may result in a Sync_Begin message from its peer. The Sync_Begin message is defined in Section 6.2.4.
Sync_Requestメッセージは、そのピアからのSync_Beginメッセージになる場合があります。 Sync_Beginメッセージはセクション6.2.4で定義されています。
The Sync_Begin message is a reply to a Sync_Request message. It is used to notify the synchronization requester whether the synchronization can be started.
Sync_Beginメッセージは、Sync_Requestメッセージへの返信です。同期を開始できるかどうかを同期リクエスタに通知するために使用されます。
The format of the Sync_Begin message is as follows:
Sync_Beginメッセージの形式は次のとおりです。
<Sync_Begin Message> ::= <Common Header>
<Error Information TLV>
The return codes are carried in the Error Information TLV. The codes are listed below:
戻りコードは、エラー情報TLVに含まれています。コードは以下のとおりです。
0: Success. Be ready to synchronize.
0：成功。同期する準備をします。
1: Failure. Malformed message received.
1：失敗。不正なメッセージを受け取りました。
2: TLV-Unknown. One or more of the TLVs was not understood.
2：TLV-不明。 1つ以上のTLVが理解されませんでした。
2001: Synch-NoReady. The data to be synchronized is not ready.
2001：Synch-NoReady。同期するデータの準備ができていません。
2002: Synch-Unsupport. The data synchronization is not supported.
2002：Synch-Unsupport。データの同期はサポートされていません。
The Sync_Data message is used to send data being synchronized between the CP and UP. The Sync_Data message has the same function and format as the Update_Request message. The difference is that there is no ACK for a Sync_Data message. An error caused by the Sync_Data message will result in a Sync_End message.
Sync_Dataメッセージは、CPとUPの間で同期されているデータを送信するために使用されます。 Sync_Dataメッセージの機能と形式は、Update_Requestメッセージと同じです。違いは、Sync_Dataメッセージに対するACKがないことです。 Sync_Dataメッセージによって発生したエラーは、Sync_Endメッセージになります。
There are two scenarios:
2つのシナリオがあります。
* Synchronization from UP to CP: Synchronize the resource data to CP.
* UPからCPへの同期：リソースデータをCPに同期します。
<Sync_Data Message> ::= <Common Header>
[<Interface Status TLV>]
[<Board Status TLV>]
* Synchronization from CP to UP: Synchronize all subscriber sessions to the UP. The Subscriber TLVs carried are those appearing in Section 7.9. As for which TLVs should be carried, it depends on the specific session data to be synchronized. The process is equivalent to the creation of a particular session. Refer to Section 5 to see more details.
* CPからUPへの同期：すべての加入者セッションをUPに同期します。伝送される加入者TLVは、セクション7.9に記載されているものです。どのTLVを伝送するかは、同期する特定のセッションデータによって異なります。このプロセスは、特定のセッションの作成と同等です。詳細については、セクション5を参照してください。
<Sync_Data Message> ::= <Common Header>
[<IPv4 Routing TLV>]
[<IPv6 Routing TLV>]
[<Subscriber TLVs>]
The Sync_End message is used to indicate the end of a synchronization process. The format of a Sync_End message is as follows:
Sync_Endメッセージは、同期プロセスの終了を示すために使用されます。 Sync_Endメッセージの形式は次のとおりです。
<Sync_End Message> ::= <Common Header>
<Error Information TLV>
The return/error codes are listed as follows:
戻りコード/エラーコードは次のとおりです。
0: Success. Synchronization finished.
0：成功。同期が終了しました。
1: Failure. Malformed message received.
1：失敗。不正なメッセージを受け取りました。
2: TLV-Unknown. One or more of the TLVs was not understood.
2：TLV-不明。 1つ以上のTLVが理解されませんでした。
The Update_Request message is a multipurpose message; it can be used to create, update, and delete subscriber sessions on a UP.
Update_Requestメッセージは多目的メッセージです。 UPで加入者セッションを作成、更新、および削除するために使用できます。
For session operations, the specific operation is controlled by the Oper field of the carried TLVs. As defined in Section 7.1, the Oper field can be set to either Update or Delete when a TLV is carried in an Update_Request message.
セッション操作の場合、特定の操作は、伝送されたTLVのOperフィールドによって制御されます。セクション7.1で定義されているように、TLVがUpdate_Requestメッセージに含まれている場合、OperフィールドはUpdateまたはDeleteに設定できます。
When the Oper field is set to Update, it means to create or update a subscriber session. If the Oper field is set to Delete, it is a request to delete a corresponding session.
OperフィールドがUpdateに設定されている場合、サブスクライバーセッションを作成または更新することを意味します。 OperフィールドがDeleteに設定されている場合、これは対応するセッションを削除する要求です。
The format of the Update_Request message is as follows:
Update_Requestメッセージの形式は次のとおりです。
<Update_Request Message> ::= <Common Header>
[<IPv4 Routing TLV>]
[<IPv6 Routing TLV>]
[<Subscriber TLVs>]
Where the Subscriber TLVs are those appearing in Section 7.9. Each Update_Request message will result in an Update_Response message, which is defined in Section 6.2.8.
サブスクライバTLVは、セクション7.9に記載されているものです。各Update_Requestメッセージは、セクション6.2.8で定義されているUpdate_Responseメッセージになります。
The Update_Response message is a response to an Update_Request message. It is used to confirm the update request (or reject it in the case of an error). The format of an Update_Response message is as follows:
Update_Responseメッセージは、Update_Requestメッセージへの応答です。更新要求を確認するために使用されます（またはエラーの場合は拒否します）。 Update_Responseメッセージの形式は次のとおりです。
<Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>]
<Error Information TLV>
The return/error codes are carried in the Error Information TLV. They are listed as follows:
リターン/エラーコードは、エラー情報TLVで伝達されます。それらは次のとおりです。
0: Success.
0：成功。
1: Failure. Malformed message received.
1：失敗。不正なメッセージを受け取りました。
2: TLV-Unknown. One or more of the TLVs was not understood.
2：TLV-不明。 1つ以上のTLVが理解されませんでした。
3001: Pool-Mismatch. The corresponding address pool cannot be found.
3001：プールの不一致。対応するアドレスプールが見つかりません。
3002: Pool-Full. The address pool is fully allocated, and no address segment is available.
3002：プールがいっぱいです。アドレスプールは完全に割り当てられており、使用可能なアドレスセグメントはありません。
3003: Subnet-Mismatch. The address pool subnet cannot be found.
3003：サブネットの不一致。アドレスプールサブネットが見つかりません。
3004: Subnet-Conflict. Subnets in the address pool have been classified into other clients.
3004：サブネットの競合。アドレスプールのサブネットは他のクライアントに分類されています。
4001: Update-Fail-No-Res. The forwarding table fails to be delivered because the forwarding resources are insufficient.
4001：Update-Fail-No-Res。転送リソースが不足しているため、転送テーブルの配信に失敗しました。
4002: QoS-Update-Success. The QoS policy takes effect.
4002：QoS-Update-Success。 QoSポリシーが有効になります。
4003: QoS-Update-Sq-Fail. Failed to process the queue in the QoS policy.
4003：QoS-Update-Sq-Fail。 QoSポリシーでキューを処理できませんでした。
4004: QoS-Update-CAR-Fail. Processing of the CAR in the QoS policy fails.
4004：QoS-Update-CAR-Fail。 QoSポリシーでのCARの処理は失敗します。
4005: Statistic-Fail-No-Res. Statistics processing failed due to insufficient statistics resources.
4005：Statistic-Fail-No-Res。統計リソースが不足しているため、統計処理が失敗しました。
The Event message is used to report subscriber session traffic statistics and detection information. The format of the Event message is as follows:
イベントメッセージは、サブスクライバセッショントラフィックの統計情報と検出情報を報告するために使用されます。イベントメッセージの形式は次のとおりです。
<Event Message> ::= <Common Header>
[<Subscriber Traffic Statistics Report TLV>]
[<Subscriber Detection Result Report TLV>]
The Report message is used to report board and interface status on a UP. The format of the Report message is as follows:
レポートメッセージは、UPのボードとインターフェイスのステータスを報告するために使用されます。レポートメッセージの形式は次のとおりです。
<Report Message> ::= <Common Header>
[<Board Status TLVs>]
[<Interface Status TLVs>]
This document defines the following resource allocation messages:
このドキュメントでは、次のリソース割り当てメッセージを定義しています。
+------+---------------------+-----------------------------+
| Type | Message Name | TLV that is carried |
+======+=====================+=============================+
| 200 | Addr_Allocation_Req | Address Allocation Request |
+------+---------------------+-----------------------------+
| 201 | Addr_Allocation_Ack | Address Allocation Response |
+------+---------------------+-----------------------------+
| 202 | Addr_Renew_Req | Address Renewal Request |
+------+---------------------+-----------------------------+
| 203 | Addr_Renew_Ack | Address Renewal Response |
+------+---------------------+-----------------------------+
| 204 | Addr_Release_Req | Address Release Request |
+------+---------------------+-----------------------------+
| 205 | Addr_Release_Ack | Address Release Response |
+------+---------------------+-----------------------------+
Table 3: Resource Allocation Messages
表3：リソース割り当てメッセージ
The Addr_Allocation_Req message is used to request CGN address allocation. The format of the Addr_Allocation_Req message is as follows:
Addr_Allocation_Reqメッセージは、CGNアドレスの割り当てを要求するために使用されます。 Addr_Allocation_Reqメッセージの形式は次のとおりです。
<Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV>
The Addr_Allocation_Ack message is a response to an Addr_Allocation_Req message. The format of the Addr_Allocation_Ack message is as follows:
Addr_Allocation_Ackメッセージは、Addr_Allocation_Reqメッセージへの応答です。 Addr_Allocation_Ackメッセージの形式は次のとおりです。
<Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV>
The Addr_Renew_Req message is used to request address renewal. The format of the Addr_Renew_Req message is as follows:
Addr_Renew_Reqメッセージは、アドレスの更新を要求するために使用されます。 Addr_Renew_Reqメッセージの形式は次のとおりです。
<Addr_Renew_Req Message> ::= <Common Header>
<Address Renewal Request TLV>
The Addr_Renew_Ack message is a response to an Addr_Renew_Req message. The format of the Addr_Renew_Req message is as follows:
Addr_Renew_Ackメッセージは、Addr_Renew_Reqメッセージへの応答です。 Addr_Renew_Reqメッセージの形式は次のとおりです。
<Addr_Renew_Ack Message> ::= <Common Header>
<Address Renewal Response TLV>
The Addr_Release_Req message is used to request address release. The format of the Addr_Release_Req message is as follows:
Addr_Release_Reqメッセージは、アドレス解放を要求するために使用されます。 Addr_Release_Reqメッセージの形式は次のとおりです。
<Addr_Release_Req Message> ::= <Common Header>
<Address Release Request TLV>
The Addr_Release_Ack message is a response to an Addr_Release_Req message. The format of the Addr_Release_Ack message is as follows:
Addr_Release_Ackメッセージは、Addr_Release_Reqメッセージへの応答です。 Addr_Release_Ackメッセージの形式は次のとおりです。
<Addr_Release_Ack Message> ::= <Common Header>
<Address Release Response TLV>
The Vendor message, in conjunction with the Vendor TLV and Vendor sub-TLV, can be used by vendors to extend S-CUSP. The Message-Type is 11. If the receiver does not recognize the message, an Error message will be returned to the sender.
ベンダーメッセージは、ベンダーTLVおよびベンダーサブTLVと組み合わせて、ベンダーがS-CUSPを拡張するために使用できます。 Message-Typeは11です。受信者がメッセージを認識しない場合、エラーメッセージが送信者に返されます。
The format of the Vendor message is as follows:
ベンダーメッセージの形式は次のとおりです。
<Vendor Message> ::= <Common Header>
<Vendor TLV>
[<any other TLVs as specified by the vendor>]
The Error message is defined to return some critical error information to the sender. If a receiver does not support the type of the received message, it MUST return an Error message to the sender.
エラーメッセージは、送信者に重要なエラー情報を返すように定義されています。受信者が受信したメッセージのタイプをサポートしていない場合は、送信者にエラーメッセージを返す必要があります。
The format of the Error message is as below:
エラーメッセージの形式は次のとおりです。
<Error Message> ::= <Common Header>
<Error Information TLV>
This section specifies the following:
このセクションでは、以下を指定します。
* The format of the TLVs that appear in S-CUSP messages,
* S-CUSPメッセージに表示されるTLVの形式、
* The format of the sub-TLVs that appear within the values of some TLVs, and
* 一部のTLVの値内に表示されるサブTLVのフォーマット、および
* The format of some basic data fields that appear within TLVs or sub-TLVs.
* TLVまたはサブTLV内に表示されるいくつかの基本的なデータフィールドの形式。
See Section 8 for a list of all defined TLVs and sub-TLVs.
定義されているすべてのTLVとサブTLVのリストについては、セクション8を参照してください。
S-CUSP messages consist of the common header specified in Section 6.1 followed by TLVs formatted as specified in this section.
S-CUSPメッセージは、セクション6.1で指定された共通ヘッダーと、このセクションで指定された形式のTLVで構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Common TLV Header
図32：共通TLVヘッダー
Oper (4 bits): For Message-Types that specify an operation on a data set, the Oper field is interpreted as Update, Delete, or Reserved as specified in Section 8.3. For all other Message-Types, the Oper field MUST be sent as zero and ignored on receipt.
Oper（4ビット）：データセットの操作を指定するMessage-Typeの場合、Operフィールドは、セクション8.3で指定されているように、Update、Delete、またはReservedとして解釈されます。他のすべてのメッセージタイプの場合、Operフィールドはゼロとして送信され、受信時に無視される必要があります。
TLV-Type (12 bits): The type of a TLV. TLV-Type specifies the interpretation and format of the Value field of the TLV. See Section 8.2.
TLV-Type（12ビット）：TLVのタイプ。 TLV-Typeは、TLVのValueフィールドの解釈と形式を指定します。セクション8.2を参照してください。
TLV-Length (2 bytes): The length of the Value portion of the TLV in bytes as an unsigned integer.
TLV-Length（2バイト）：TLVの値部分の長さ（符号なし整数としてのバイト単位）。
Value (variable length): This is the portion of the TLV whose size is given by TLV-Length. It consists of fields, frequently using one of the basic data field types (see Section 7.2) and sub-TLVs (see Section 7.3).
値（可変長）：これは、サイズがTLV-Lengthで指定されるTLVの部分です。これはフィールドで構成され、頻繁に基本データフィールドタイプ（セクション7.2を参照）とサブTLV（セクション7.3を参照）の1つを使用します。
This section specifies the binary format of several standard basic data fields that are used within other data structures in this specification.
このセクションでは、この仕様の他のデータ構造内で使用されるいくつかの標準的な基本データフィールドのバイナリ形式を指定します。
STRING: 0 to 255 octets. Will be encoded as a sub-TLV (see Section 7.3) to provide the length. The use of this data type in S-CUSP is to provide convenient labels for use by network operators in configuring and debugging their networks and interpreting S-CUSP messages. Subscribers will not normally see these labels. They are normally interpreted as ASCII [RFC20].
STRING：0〜255オクテット。長さを提供するために、サブTLV（セクション7.3を参照）としてエンコードされます。 S-CUSPでのこのデータタイプの使用は、ネットワークオペレーターがネットワークの構成とデバッグ、およびS-CUSPメッセージの解釈に使用する便利なラベルを提供することです。通常、サブスクライバーにはこれらのラベルは表示されません。それらは通常、ASCII [RFC20]として解釈されます。
MAC-Addr: 6 octets. Ethernet MAC address [RFC7042].
MACアドレス：6オクテット。イーサネットMACアドレス[RFC 7042]。
IPv4-Address: 8 octets. 4 octets of the IPv4 address value followed by a 4-octet address mask in the format XXX.XXX.XXX.XXX.
IPv4-Address：8オクテット。 IPv4アドレス値の4オクテットと、それに続くXXX.XXX.XXX.XXX形式の4オクテットアドレスマスク。
IPv6-Address: 20 octets. 16 octets of the IPv6 address followed by a 4-octet integer n in the range of 0 to 128, which gives the address mask as the one's complement of 2**(128-n) - 1.
IPv6-アドレス：20オクテット。 IPv6アドレスの16オクテット、それに続く0〜128の範囲の4オクテット整数n。これにより、アドレスマスクが2 **（128-n）-1の補数として与えられます。
VLAN ID: 2 octets. As follows [802.1Q]:
VLAN ID：2オクテット。次のように[802.1Q]：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRI |D| VLAN-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PRI: Priority. Default value 7.
PRI：優先度。デフォルト値7。
D: Drop Eligibility Indicator (DEI). Default value 0.
D：適格性インジケーター（DEI）を削除します。デフォルト値は0です。
VLAN-ID: Unsigned integer in the range 1-4094. (0 and 4095 are not valid VLAN IDs [802.1Q].)
VLAN-ID：1〜4094の範囲の符号なし整数。 （0と4095は有効なVLAN IDではありません[802.1Q]。）
In some cases, the Value portion of a TLV, as specified in Section 7.1, can contain one or more sub-TLVs formatted as follows:
場合によっては、セクション7.1で指定されているTLVの値の部分に、次のようにフォーマットされた1つ以上のサブTLVを含めることができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 33: Sub-TLV Header
図33：サブTLVヘッダー
Type (2 bytes): The type of a sub-TLV. The Type field specifies the interpretation and format of the Value field of the TLV. Sub-TLV type values have the same meaning regardless of the TLV type of the TLV within which the sub-TLV occurs. See Section 8.4.
タイプ（2バイト）：サブTLVのタイプ。 Typeフィールドは、TLVのValueフィールドの解釈と形式を指定します。サブTLVタイプの値は、サブTLVが発生するTLVのTLVタイプに関係なく同じ意味を持ちます。セクション8.4を参照してください。
Length (2 bytes): The length of the Value portion of the sub-TLV in bytes as an unsigned integer.
長さ（2バイト）：サブTLVの値部分の長さ（符号なし整数としてのバイト単位）。
Value (variable length): This is the Value portion of the sub-TLV whose size is given by Length.
値（可変長）：これは、長さがサイズで指定されるサブTLVの値部分です。
The sub-TLVs currently specified are defined in the following subsections.
現在指定されているサブTLVは、次のサブセクションで定義されています。
This document defines the following name sub-TLVs that are used to carry the name of the corresponding object. The length of each of these sub-TLVs is variable from 1 to 255 octets. The value is of type STRING padded with zero octets to a length in octets that is an integer multiple of 4.
このドキュメントでは、対応するオブジェクトの名前を伝えるために使用される次の名前サブTLVを定義します。これらの各サブTLVの長さは、1〜255オクテットで可変です。値のタイプはSTRINGで、4の整数倍であるオクテット単位の長さにゼロオクテットが埋め込まれています。
+------+---------------------+------------------------------------+
| Type | Sub-TLV Name | Meaning |
+======+=====================+====================================+
| 1 | VRF-Name | The name of a VRF |
+------+---------------------+------------------------------------+
| 2 | Ingress-QoS-Profile | The name of an ingress QoS profile |
+------+---------------------+------------------------------------+
| 3 | Egress-QoS-Profile | The name of an egress QoS profile |
+------+---------------------+------------------------------------+
| 4 | User-ACL-Policy | The name of an ACL policy |
+------+---------------------+------------------------------------+
| 5 | Multicast-ProfileV4 | The name of an IPv4 multicast |
| | | profile |
+------+---------------------+------------------------------------+
| 6 | Multicast-ProfileV6 | The name of an IPv6 multicast |
| | | profile |
+------+---------------------+------------------------------------+
| 9 | NAT-Instance | The name of a NAT instance |
+------+---------------------+------------------------------------+
| 10 | Pool-Name | The name of an address pool |
+------+---------------------+------------------------------------+
Table 4: Name Sub-TLVs
表4：サブTLVに名前を付ける
The Ingress-CAR sub-TLV indicates the authorized upstream Committed Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR sub-TLV is 7. The sub-TLV length is 16. The format is as shown in Figure 34.
Ingress-CARサブTLVは、承認されたアップストリームの認定アクセスレート（CAR）パラメータを示します。 Ingress-CARサブTLVのサブTLVタイプは7です。サブTLVの長さは16です。フォーマットは図34に示すとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Ingress-CAR Sub-TLV
図34：Ingress-CAR Sub-TLV
Where:
ただし：
CIR (4 bytes): Guaranteed rate in bits/second.
CIR（4バイト）：ビット/秒単位の保証レート。
PIR (4 bytes): Burst rate in bits/second.
PIR（4バイト）：ビット/秒のバーストレート。
CBS (4 bytes): The token bucket in bytes.
CBS（4バイト）：バイト単位のトークンバケット。
PBS (4 bytes): Burst token bucket in bytes.
PBS（4バイト）：バイト単位のバーストトークンバケット。
These fields are unsigned integers. More details about CIR, PIR, CBS, and PBS can be found in [RFC2698].
これらのフィールドは符号なし整数です。 CIR、PIR、CBS、およびPBSの詳細については、[RFC2698]を参照してください。
The Egress-CAR sub-TLV indicates the authorized downstream Committed Access Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub-TLV is 8. Its sub-TLV length is 16 octets. The format of the value part is as defined below.
Egress-CARサブTLVは、承認されたダウンストリームの認定アクセスレート（CAR）パラメーターを示します。 Egress-CARサブTLVのサブTLVタイプは8です。そのサブTLV長は16オクテットです。値の部分のフォーマットは以下のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: Egress-CAR Sub-TLV
図35：出力CARサブTLV
Where:
ただし：
CIR (4 bytes): Guaranteed rate in bits/second.
CIR（4バイト）：ビット/秒単位の保証レート。
PIR (4 bytes): Burst rate in bits/second.
PIR（4バイト）：ビット/秒のバーストレート。
CBS (4 bytes): The token bucket in bytes.
CBS（4バイト）：バイト単位のトークンバケット。
PBS (4 bytes): Burst token bucket in bytes.
PBS（4バイト）：バイト単位のバーストトークンバケット。
These fields are unsigned integers. More details about CIR, PIR, CBS, and PBS can be found in [RFC2698].
これらのフィールドは符号なし整数です。 CIR、PIR、CBS、およびPBSの詳細については、[RFC2698]を参照してください。
The If-Desc sub-TLV is defined to designate an interface. It is an optional sub-TLV that may be carried in those TLVs that have an If-Index or Out-If-Index field. The If-Desc sub-TLV is used as a locally unique identifier within a BNG.
If-DescサブTLVは、インターフェイスを指定するために定義されています。これは、If-IndexまたはOut-If-Indexフィールドを持つTLVで伝送されるオプションのサブTLVです。 If-DescサブTLVは、BNG内でローカルに一意の識別子として使用されます。
The sub-TLV type is 11. The sub-TLV length is 12 octets. The format depends on the If-Type (Section 8.6). The format of the value part is as follows:
サブTLVタイプは11です。サブTLV長は12オクテットです。形式は、If-Type（セクション8.6）によって異なります。値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (1-5)| Chassis | Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Slot | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc Sub-TLV (Physical Port)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Type (6-7) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logic-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc Sub-TLV (Virtual Port)
Figure 36: If-Desc Sub-TLV Formats
図36：If-DescサブTLV形式
Where:
ただし：
If-Type: 8 bits in length. The value of this field indicates the type of an interface. The If-Type values defined in this document are listed in Section 8.6.
If-Type：長さが8ビット。このフィールドの値は、インターフェースのタイプを示します。このドキュメントで定義されているIf-Type値は、セクション8.6にリストされています。
Chassis (8 bits): Identifies the chassis that the interface belongs to.
シャーシ（8ビット）：インターフェースが属するシャーシを識別します。
Slot (16 bits): Identifies the slot that the interface belongs to.
スロット（16ビット）：インターフェースが属するスロットを識別します。
Sub-Slot (16 bits): Identifies the sub-slot the interface belongs to.
サブスロット（16ビット）：インターフェースが属するサブスロットを識別します。
Port Number (16 bits): An identifier of a physical port/interface (e.g., If-Type: 1-5). It is locally significant within the slot/sub-slot.
ポート番号（16ビット）：物理ポート/インターフェースの識別子（例：If-Type：1-5）。これは、スロット/サブスロット内でローカルに重要です。
Sub-Port Number (32 bits): An identifier of the sub-port. Locally significant within its "parent" port (physical or virtual).
サブポート番号（32ビット）：サブポートの識別子。 「親」ポート（物理または仮想）内でローカルに重要です。
Logic-ID (32 bits): An identifier of a virtual interface (e.g., If-Type: 6-7).
Logic-ID（32ビット）：仮想インターフェースの識別子（例：If-Type：6-7）。
The IPv6 Address List sub-TLV is used to convey one or more IPv6 addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV type is 12. The sub-TLV length is variable.
IPv6アドレスリストサブTLVは、1つ以上のIPv6アドレスを伝達するために使用されます。 IPv6サブスクライバーTLVで伝送されます。サブTLVタイプは12です。サブTLVの長さは可変です。
The format of the value part of the IPv6 Address List sub-TLV is as follows:
IPv6アドレスリストサブTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: IPv6 Address List Sub-TLV
図37：IPv6アドレスリストサブTLV
Where:
ただし：
IPv6 Address (IPv6-Address): Each IP Address is of type IP-Address and carries an IPv6 address and length.
IPv6アドレス（IPv6-Address）：各IPアドレスはタイプIP-Addressで、IPv6アドレスと長さを持ちます。
The Vendor sub-TLV is intended to be used inside the Value portion of the Vendor TLV (Section 7.13). It provides a Sub-Type that effectively extends the sub-TLV type in the sub-TLV header and provides for versioning of Vendor sub-TLVs.
Vendor sub-TLVは、Vendor TLVのValue部分内で使用することを目的としています（セクション7.13）。これは、サブTLVヘッダーのサブTLVタイプを効果的に拡張するサブタイプを提供し、ベンダーサブTLVのバージョン管理を提供します。
The value part of the Vendor sub-TLV is formatted as follows:
ベンダーサブTLVの値の部分は、次のようにフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (other as specified by vendor) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Vendor Sub-TLV
図38：ベンダーサブTLV
Where:
ただし：
Sub-TLV type: 13.
サブTLVタイプ：13。
Sub-TLV length: Variable.
サブTLV長：可変。
Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865].
ベンダーID（4バイト）：RADIUS [RFC2865]で定義されているベンダーID。
Sub-Type (2 bytes): Used by the vendor to distinguish multiple different sub-TLVs.
サブタイプ（2バイト）：複数の異なるサブTLVを区別するためにベンダーによって使用されます。
Sub-Type-Version (2 bytes): Used by the vendor to distinguish different versions of a vendor-defined sub-TLV Sub-Type.
サブタイプバージョン（2バイト）：ベンダー定義のサブTLVサブタイプの異なるバージョンを区別するためにベンダーによって使用されます。
Value: As specified by the vendor.
値：ベンダーが指定したとおり。
Since vendor code will be handling the sub-TLV after the Vendor-ID field is recognized, the remainder of the sub-TLV can be organized however the vendor wants. But it desirable for a vendor to be able to define multiple different Vendor sub-TLVs and to keep track of different versions of its vendor-defined sub-TLVs. Thus, it is RECOMMENDED that the vendor assign a Sub-Type value for each of that vendor's sub-TLVs that is different from other Sub-Type values that vendor has used. Also, when modifying a vendor-defined sub-TLV in a way potentially incompatible with a previous definition, the vendor SHOULD increase the value it is using in the Sub-Type-Version field.
ベンダーIDフィールドが認識された後、ベンダーコードがサブTLVを処理するため、ベンダーが望む方法でサブTLVの残りの部分を整理できます。ただし、ベンダーが複数の異なるベンダーサブTLVを定義でき、ベンダー定義のサブTLVの異なるバージョンを追跡できることが望ましい。したがって、ベンダーが使用した他のサブタイプ値とは異なる、そのベンダーのサブTLVごとにサブタイプ値を割り当てることをお勧めします。また、ベンダー定義のサブTLVを以前の定義と互換性がない可能性がある方法で変更する場合、ベンダーはSub-Type-Versionフィールドで使用している値を増やす必要があります（SHOULD）。
The Hello TLV is defined to be carried in the Hello message for version and capabilities negotiation. It indicates the S-CUSP sub-version and capabilities supported. The format of the value part of the Hello TLV is as follows:
Hello TLVは、バージョンと機能のネゴシエーションのためにHelloメッセージで伝達されるように定義されています。 S-CUSPサブバージョンとサポートされる機能を示します。 Hello TLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerSupported |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: Hello TLV
図39：Hello TLV
Where:
ただし：
TLV type: 100.
TLVタイプ：100。
TLV length: 12 octets.
TLV長：12オクテット。
VerSupported: 32 bits in length. It is a bit map of the Sub-Versions of S-CUSP that the sender supports. This document specifies Sub-Version zero of Major Version 1, that is, Version 1.0. The VerSupported field MUST be nonzero. The VerSupported bits are numbered from 0 as the most significant bit. Bit 0 indicates support of Sub-Version zero, bit 1 indicates support of Sub-Version one, etc.
VerSupported：長さ32ビット。これは、送信者がサポートするS-CUSPのサブバージョンのビットマップです。このドキュメントでは、メジャーバージョン1のサブバージョンゼロ、つまりバージョン1.0を指定しています。 VerSupportedフィールドはゼロ以外でなければなりません。 VerSupportedビットには、最上位ビットとして0から番号が付けられます。ビット0はサブバージョン0のサポートを示し、ビット1はサブバージョン1のサポートを示します。
Vendor-ID: 4 bytes in length. Vendor ID, as defined in RADIUS [RFC2865].
ベンダーID：4バイトの長さ。 RADIUS [RFC2865]で定義されているベンダーID。
Capabilities: 32 bits in length. Flags that indicate the support of particular capabilities by the sender of the Hello. No capabilities are defined in this document, so implementations of the version specified herein will set this field to zero. The Capabilities field of the Hello TLV MUST be checked before any other TLVs in the Hello because capabilities defined in the future might extend existing TLVs or permit new TLVs.
機能：32ビット長。 Helloの送信者による特定の機能のサポートを示すフラグ。このドキュメントでは機能が定義されていないため、ここで指定されたバージョンの実装は、このフィールドをゼロに設定します。将来定義される機能は既存のTLVを拡張するか、新しいTLVを許可する可能性があるため、Hello TLVの機能フィールドは、Helloの他のTLVよりも前にチェックする必要があります。
After the exchange of Hello messages, the CP and UP each perform a logical AND of the Sub-Version supported by the CP and the UP and separately perform a logical AND of the Capabilities field for the CP and the UP.
Helloメッセージの交換後、CPとUPはそれぞれ、CPとUPによってサポートされるサブバージョンの論理ANDを実行し、CPとUPの機能フィールドの論理ANDを個別に実行します。
If the result of the AND of the Sub-Versions supported is zero, then no session can be established, and the connection is torn down. If the result of the AND of the Sub-Versions supported is nonzero, then the session uses the highest Sub-Version supported by both the CP and UP.
サポートされているサブバージョンのANDの結果がゼロの場合、セッションを確立できず、接続が切断されます。サポートされているサブバージョンのANDの結果がゼロ以外の場合、セッションはCPとUPの両方でサポートされている最高のサブバージョンを使用します。
For example, if one side supports Sub-Versions 1, 3, 4, and 5 (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4 (VerSupported = 0x38000000), then 3 and 4 are the Sub-Versions in common, and 4 is the highest Sub-Version supported by both sides. So Sub-Version 4 is used for the session that has been negotiated.
たとえば、一方がサブバージョン1、3、4、および5（VerSupported = 0x5C000000）をサポートし、もう一方が2、3、および4（VerSupported = 0x38000000）をサポートする場合、3および4は共通であり、4は両側でサポートされる最高のサブバージョンです。したがって、ネゴシエートされたセッションにはサブバージョン4が使用されます。
The result of the logical AND of the Capabilities bits will show what additional capabilities both sides support. If this result is zero, there are no such capabilities, so none can be used during the session. If this result is nonzero, it shows the additional capabilities that can be used during the session. The CP and the UP MUST NOT use a capability unless both advertise support.
機能ビットの論理積の結果は、両側がサポートする追加機能を示します。この結果がゼロの場合、そのような機能はないため、セッション中に使用できる機能はありません。この結果がゼロ以外の場合は、セッション中に使用できる追加機能が表示されます。 CPとUPは、両方がサポートをアドバタイズしない限り、機能を使用してはなりません（MUST NOT）。
The Keepalive TLV is carried in the Hello message. It provides timing information for this feature. The format of the value part of the Keepalive TLV is as follows:
キープアライブTLVは、Helloメッセージで伝送されます。この機能のタイミング情報を提供します。キープアライブTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive | DeadTimer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: Keepalive TLV
図40：キープアライブTLV
Where:
ただし：
TLV type: 102.
TLVタイプ：102。
TLV length: 4 octets.
TLV長：4オクテット。
Keepalive (8 bits): Indicates the maximum interval (in seconds) between two consecutive S-CUSP messages sent by the sender of the message containing this TLV as an unsigned integer. The minimum value for the Keepalive field is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the Keepalive frequency is 30 seconds.
キープアライブ（8ビット）：このTLVを符号なし整数として含むメッセージの送信者によって送信された2つの連続したS-CUSPメッセージ間の最大間隔（秒単位）を示します。キープアライブフィールドの最小値は1秒です。 0に設定すると、セッションが確立されると、それ以上のキープアライブメッセージはリモートピアに送信されません。キープアライブ頻度の推奨値は30秒です。
DeadTimer (8 bits in length): Specifies the amount of time as an unsigned integer number of seconds, after the expiration of which, the S-CUSP peer can declare the session with the sender of the Hello message to be down if no S-CUSP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive.
DeadTimer（8ビット長）：時間の量を符号なし整数の秒数で指定します。有効期限が切れた後、S-CUSPピアはHelloメッセージの送信者とのセッションがS-先端メッセージを受信しました。 DeadTimerは0に設定する必要があり（SHOULD）、Keepaliveが0に設定されている場合は無視する必要があります。DeadTimerの推奨値は、Keepaliveの値の4倍です。
Reserved: The Reserved bits MUST be sent as zero and ignored on receipt.
予約済み：予約済みビットはゼロとして送信され、受信時に無視される必要があります。
The Error Information TLV is a common TLV that can be used in many responses (e.g., Update_Response message) and ACK messages (e.g., Addr_Allocation_Ack message). It is used to convey the information about an error in the received S-CUSP message. The format of the value part of the Error Information TLV is as follows:
エラー情報TLVは、多くの応答（Update_Responseメッセージなど）およびACKメッセージ（Addr_Allocation_Ackメッセージなど）で使用できる一般的なTLVです。受信したS-CUSPメッセージのエラーに関する情報を伝えるために使用されます。エラー情報TLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Type | Reserved | TLV-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Error Information TLV
図41：エラー情報TLV
Where:
ただし：
TLV type: 101.
TLVタイプ：101。
TLV length: 8 octets.
TLV長：8オクテット。
Message-Type (1 byte): This parameter is the message type of the message containing an error.
Message-Type（1バイト）：このパラメーターは、エラーを含むメッセージのメッセージタイプです。
Reserved (1 byte): MUST be sent as zero and ignored on receipt.
予約済み（1バイト）：ゼロとして送信し、受信時に無視する必要があります。
TLV-Type (2 bytes): Indicates which TLV caused the error.
TLV-Type（2バイト）：エラーを引き起こしたTLVを示します。
Error Code: 4 bytes in length. Indicate the specific Error Code (see Section 8.5).
エラーコード：4バイトの長さ。特定のエラーコードを示します（セクション8.5を参照）。
The BAS Function TLV is used by a CP to control the access mode, authentication methods, and other related functions of an interface on a UP.
BAS機能TLVは、アクセスモード、認証方法、およびUP上のインターフェイスの他の関連機能を制御するためにCPによって使用されます。
The format of the BAS Function TLV value part is as follows:
BAS機能のTLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Mode | Auth-Method4 | Auth-Method6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: BAS Function TLV
図42：BAS機能TLV
Where:
ただし：
TLV type: 1.
TLVタイプ：1。
TLV length: Variable.
TLVの長さ：可変。
If-Index: 4 bytes in length, a unique identifier of an interface of a BNG.
If-Index：長さ4バイト、BNGのインターフェースの一意の識別子。
Access-Mode: 1 byte in length. It indicates the access mode of the interface. The defined values are listed in Section 8.7.
アクセスモード：長さ1バイト。インターフェースのアクセスモードを示します。定義された値はセクション8.7にリストされています。
Auth-Method4: 1 byte in length. It indicates the authentication on this interface for the IPv4 scenario. This field is defined as a bitmap. The bits defined in this document are listed in Section 8.8. Other bits are reserved and MUST be sent as zero and ignored on receipt.
Auth-Method4：長さが1バイト。これは、IPv4シナリオのこのインターフェースでの認証を示します。このフィールドはビットマップとして定義されています。このドキュメントで定義されているビットは、セクション8.8にリストされています。他のビットは予約されており、ゼロとして送信し、受信時に無視する必要があります。
Auth-Method6: 1 byte in length. It indicates the authentication on this interface for the IPv6 scenario. This field is defined as a bitmap. The bits defined in this document are listed in Section 8.8. Other bits are reserved and MUST be sent as zero and ignored on receipt.
Auth-Method6：長さが1バイト。これは、IPv6シナリオのこのインターフェースでの認証を示します。このフィールドはビットマップとして定義されています。このドキュメントで定義されているビットは、セクション8.8にリストされています。他のビットは予約されており、ゼロとして送信し、受信時に無視する必要があります。
Sub-TLVs: The IF-Desc sub-TLV can be carried.
サブTLV：IF-DescサブTLVを伝送できます。
If-Desc sub-TLV: Carries the interface information.
If-Desc sub-TLV：インターフェース情報を伝達します。
Flags: The Flags field is defined as follows:
フラグ：[フラグ]フィールドは次のように定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 43: Interface Flags
図43：インターフェイスフラグ
Where:
ただし：
F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a subscriber to go online.
F（IPv4トリガー）ビット：IPv4パケットがサブスクライバーをオンラインにトリガーできるかどうかを示します。
1: Enabled.
1：有効。
0: Disabled.
0：無効。
S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a subscriber to go online.
S（IPv6トリガー）ビット：IPv6パケットがサブスクライバーをオンラインにトリガーできるかどうかを示します。
1: Enabled.
1：有効。
0: Disabled.
0：無効。
A (ARP Trigger) bit: Indicates whether ARP packets can trigger a subscriber to go online.
A（ARPトリガー）ビット：ARPパケットがサブスクライバーをオンラインにトリガーできるかどうかを示します。
1: Enabled.
1：有効。
0: Disabled.
0：無効。
N (ND Trigger) bit: Indicates whether ND packets can trigger a subscriber to go online.
N（NDトリガー）ビット：NDパケットがサブスクライバーをトリガーしてオンラインになるかどうかを示します。
1: Enabled.
1：有効。
0: Disabled.
0：無効。
I (IPoE-Flow-Check): Used for UP detection.
I（IPoE-Flow-Check）：UP検出に使用されます。
1: Enable traffic detection.
1：トラフィック検出を有効にします。
0: Disable traffic detection.
0：トラフィック検出を無効にします。
P (PPP-Flow-Check) bit: Used for UP detection.
P（PPP-Flow-Check）ビット：UP検出に使用されます。
1: Enable traffic detection.
1：トラフィック検出を有効にします。
0: Disable traffic detection.
0：トラフィック検出を無効にします。
X (ARP-Proxy) bit: Indicates whether ARP proxy is enabled on the interface.
X（ARPプロキシ）ビット：インターフェイスでARPプロキシが有効かどうかを示します。
1: The interface is enabled with ARP proxy and can process ARP requests across different network ports and VLANs.
1：インターフェイスはARPプロキシで有効になっており、異なるネットワークポートおよびVLAN全体でARP要求を処理できます。
0: The ARP proxy is not enabled on the interface and only the ARP requests of the same network port and VLAN are processed.
0：インターフェイスでARPプロキシが有効になっておらず、同じネットワークポートとVLANのARPリクエストのみが処理されます。
Y (ND-Proxy) bit: Indicates whether ND proxy is enabled on the interface.
Y（NDプロキシ）ビット：インターフェースでNDプロキシが有効かどうかを示します。
1: The interface is enabled with ND proxy and can process ND requests across different network ports and VLANs.
1：インターフェースはNDプロキシで有効になっており、異なるネットワークポートとVLANにわたってNDリクエストを処理できます。
0: The ND proxy is not enabled on the interface and only the ND requests of the same network port and VLAN are processed.
0：インターフェイスでNDプロキシが有効になっておらず、同じネットワークポートとVLANのNDリクエストのみが処理されます。
MBZ: Reserved bits that MUST be sent as zero and ignored on receipt.
MBZ：予約ビット。ゼロとして送信し、受信時に無視する必要があります。
Typically, after an S-CUSP session is established between a UP and a CP, the CP will allocate one or more blocks of IP addresses to the UP. Those IP addresses will be allocated to subscribers who will dial-up (as defined in Section 4.3.1) to the UP. To make sure that other nodes within the network learn how to reach those IP addresses, the CP needs to install one or more routes that can reach those IP addresses on the UP and notify the UP to advertise the routes to the network.
通常、UPとCPの間にS-CUSPセッションが確立された後、CPはIPアドレスの1つ以上のブロックをUPに割り当てます。これらのIPアドレスは、（セクション4.3.1で定義されているように）UPにダイヤルアップする加入者に割り当てられます。ネットワーク内の他のノードがこれらのIPアドレスに到達する方法を確実に学習するために、CPは、UP上のIPアドレスに到達できる1つ以上のルートをインストールし、ネットワークにルートをアドバタイズするようUPに通知する必要があります。
The Routing TLVs are used by a CP to notify a UP of the updates to network routing information. They can be carried in the Update_Request message and Sync_Data message.
ルーティングTLVは、ネットワークルーティング情報の更新をUPに通知するためにCPによって使用されます。これらは、Update_RequestメッセージとSync_Dataメッセージで伝達できます。
The IPv4 Routing TLV is used to carry information related to IPv4 network routing.
IPv4ルーティングTLVは、IPv4ネットワークルーティングに関連する情報を伝達するために使用されます。
The format of the TLV value part is as below:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 44: IPv4 Routing TLV
図44：IPv4ルーティングTLV
Where:
ただし：
TLV type: 7.
TLVタイプ：7。
TLV length: Variable.
TLVの長さ：可変。
User-ID: 4 bytes in length. This field carries the user identifier. It is filled with all Fs when a non-user route is delivered to the UP.
ユーザーID：4バイトの長さ。このフィールドには、ユーザーIDが含まれます。非ユーザールートがUPに配信されると、すべてのFで埋められます。
Dest-Address (IPv4-Address type): Identifies the destination address.
Dest-Address（IPv4-Addressタイプ）：宛先アドレスを識別します。
Next-Hop (IPv4-Address type): Identifies the next-hop address.
Next-Hop（IPv4-Addressタイプ）：ネクストホップアドレスを識別します。
Out-If-Index (4 bytes): Indicates the interface index.
Out-If-Index（4バイト）：インターフェースのインデックスを示します。
Cost (4 bytes): The cost value of the route.
コスト（4バイト）：ルートのコスト値。
Tag (4 bytes): The tag value of the route.
タグ（4バイト）：ルートのタグ値。
Route-Type (2 bytes): The value of this field indicates the route type. The values defined in this document are listed in Section 8.9.
Route-Type（2バイト）：このフィールドの値は、ルートタイプを示します。このドキュメントで定義されている値は、セクション8.9にリストされています。
Advertise-Flag: 1 bit shown as "A" in the figure above (Figure 44). Indicates whether the UP should advertise the route. The following flag values are defined:
Advertise-Flag：上の図（図44）で「A」として示されている1ビット。 UPがルートをアドバタイズする必要があるかどうかを示します。次のフラグ値が定義されています。
0: Not advertised.
0：アドバタイズされません。
1: Advertised.
1：アドバタイズされます。
Sub-TLVs: The VRF-Name and/or If-Desc sub-TLVs can be carried.
サブTLV：VRF名やIf-DescサブTLVを伝送できます。
VRF-Name sub-TLV: Indicates which VRF the route belongs to.
VRF-Name sub-TLV：ルートが属するVRFを示します。
If-Desc sub-TLV: Carries the interface information.
If-Desc sub-TLV：インターフェース情報を伝達します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The IPv6 Routing TLV is used to carry IPv6 network routing information.
IPv6ルーティングTLVは、IPv6ネットワークルーティング情報を伝達するために使用されます。
The format of the value part of this TLV is as follows:
このTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 45: IPv6 Routing TLV
図45：IPv6ルーティングTLV
Where:
ただし：
TLV type: 8.
TLVタイプ：8。
TLV length: Variable.
TLVの長さ：可変。
User-ID: 4 bytes in length. This field carries the user identifier. This field is filled with all Fs when a non-user route is delivered to the UP.
ユーザーID：4バイトの長さ。このフィールドには、ユーザーIDが含まれます。非ユーザールートがUPに配信されると、このフィールドにはすべてのFが入ります。
IPv6 Dest-Address (IPv6-Address type): Identifies the destination address.
IPv6 Dest-Address（IPv6-Addressタイプ）：宛先アドレスを識別します。
IPv6 Next-Hop (IPv6-Address type): Identifies the next-hop address.
IPv6ネクストホップ（IPv6-アドレスタイプ）：ネクストホップアドレスを識別します。
Out-If-Index (4 bytes): Indicates the interface index.
Out-If-Index（4バイト）：インターフェースのインデックスを示します。
Cost (4 bytes): This is the cost value of the route.
コスト（4バイト）：これはルートのコスト値です。
Tag (4 bytes): The tag value of the route.
タグ（4バイト）：ルートのタグ値。
Route-Type (2 bytes): The value of this field indicates the route type. The values defined in this document are listed in Section 8.9.
Route-Type（2バイト）：このフィールドの値は、ルートタイプを示します。このドキュメントで定義されている値は、セクション8.9にリストされています。
Advertise-Flag: 1 bit shown as "A" in the figure above (Figure 45). Indicates whether the UP should advertise the route. The following flags are defined:
Advertise-Flag：上の図（図45）で「A」として示されている1ビット。 UPがルートをアドバタイズする必要があるかどうかを示します。次のフラグが定義されています。
0: Not advertised.
0：アドバタイズされません。
1: Advertised.
1：アドバタイズされます。
Sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried.
サブTLV：If-DescおよびVRF-NameサブTLVを伝送できます。
VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs.
VRF-Name sub-TLV：サブスクライバーが属するVRFを示します。
If-Desc sub-TLV: Carries the interface information.
If-Desc sub-TLV：インターフェース情報を伝達します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The Subscriber TLVs are defined for a CP to send the basic information about a user to a UP.
サブスクライバーTLVは、CPがユーザーに関する基本情報をUPに送信するために定義されます。
The Basic Subscriber TLV is used to carry the common information for all kinds of access subscribers. It is carried in an Update_Request message.
基本サブスクライバTLVは、あらゆる種類のアクセスサブスクライバの共通情報を伝達するために使用されます。 Update_Requestメッセージで伝達されます。
The format of the Basic Subscriber TLV value part is as follows:
基本サブスクライバーTLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Oper-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Type |Sub-Access-Type| Account-Type | Address Family|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect-Times | Detect-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 46: Basic Subscriber TLV
図46：基本的なサブスクライバーTLV
Where:
ただし：
TLV type: 2.
TLVタイプ：2。
TLV length: Variable.
TLVの長さ：可変。
User-ID (4 bytes): The identifier of a subscriber.
ユーザーID（4バイト）：サブスクライバーのID。
Session-ID (4 bytes): Session ID of a PPPoE subscriber. The value zero identifies a non-PPPoE subscriber.
セッションID（4バイト）：PPPoEサブスクライバーのセッションID。値0は非PPPoE加入者を識別します。
User-MAC (MAC-Addr type): The MAC address of a subscriber.
User-MAC（MAC-Addrタイプ）：サブスクライバーのMACアドレス。
Oper-ID (1 byte): Indicates the ID of an operation performed by a user. This field is carried in the response from the UP.
Oper-ID（1バイト）：ユーザーが実行した操作のIDを示します。このフィールドは、UPからの応答で運ばれます。
Reserved (1 byte): MUST be sent as zero and ignored on receipt.
予約済み（1バイト）：ゼロとして送信し、受信時に無視する必要があります。
Access-Type (1 byte): Indicates the type of subscriber access. Values defined in this document are listed in Section 8.10.
Access-Type（1バイト）：加入者アクセスのタイプを示します。このドキュメントで定義されている値は、セクション8.10にリストされています。
Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP relay is used.
サブアクセスタイプ（1バイト）：PPP終端またはPPPリレーのどちらを使用するかを示します。
0: Reserved.
0：予約済み。
1: PPP Relay (for LAC).
1：PPPリレー（LAC用）。
2: PPP termination (for LNS).
2：PPP終了（LNSの場合）。
Account-Type (1 byte): Indicates whether traffic statistics are collected independently.
Account-Type（1バイト）：トラフィック統計が個別に収集されるかどうかを示します。
0: Collects statistics on IPv4 and IPv6 traffic of terminals independently.
0：端末のIPv4およびIPv6トラフィックの統計を個別に収集します。
1: Collects statistics on IPv4 and IPv6 traffic of terminals.
1：端末のIPv4およびIPv6トラフィックに関する統計を収集します。
Address Family (1 byte): The type of IP address.
アドレスファミリ（1バイト）：IPアドレスのタイプ。
1: IPv4.
1：IPv4。
2: IPv6.
2：IPv6。
3: Dual stack.
3：デュアルスタック。
C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. The default value of PRI is 7, the value of DEI is 0, and the value of VID is 1-4094. The PRI value can also be obtained by parsing terminal packets.
C-VID（VLAN-ID）：内部VLAN IDを示します。値0は、VLAN IDが無効であることを示します。 PRIのデフォルト値は7、DEIの値は0、VIDの値は1〜4094です。 PRI値は、端末パケットを解析することでも取得できます。
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that for C-VID.
P-VID（VLAN-ID）：外部VLAN IDを示します。値0は、VLAN IDが無効であることを示します。形式はC-VIDと同じです。
Detect-Times (2 bytes): Number of detection timeout times. The value 0 indicates that no detection is performed.
Detect-Times（2バイト）：検出タイムアウト時間の数。値0は、検出が実行されないことを示します。
Detect-Interval (2 bytes): Detection interval in seconds.
Detect-Interval（2バイト）：秒単位の検出間隔。
If-Index (4 bytes): Interface index.
If-Index（4バイト）：インターフェースインデックス。
Sub-TLVs: The VRF-Name sub-TLV and If-Desc sub-TLV can be carried.
サブTLV：VRF名のサブTLVとIf-DescサブTLVを伝送できます。
VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs.
VRF-Name sub-TLV：サブスクライバーが属するVRFを示します。
If-Desc sub-TLV: Carries the interface information.
If-Desc sub-TLV：インターフェース情報を伝達します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The PPP Subscriber TLV is defined to carry PPP information of a user from a CP to a UP. It will be carried in an Update_Request message when PPPoE or L2TP access is used.
PPPサブスクライバーTLVは、ユーザーのPPP情報をCPからUPに伝送するように定義されています。 PPPoEまたはL2TPアクセスが使用されている場合、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSS-Value | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 47: PPP Subscriber TLV
図47：PPPサブスクライバーTLV
Where:
ただし：
TLV type: 3.
TLVタイプ：3。
TLV length: 12 octets.
TLV長：12オクテット。
User-ID (4 bytes): The identifier of a subscriber.
ユーザーID（4バイト）：サブスクライバーのID。
MSS-Value (2 bytes): Indicates the MSS value (in bytes).
MSS値（2バイト）：MSS値（バイト単位）を示します。
MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled.
MSS-Enable（M）（1ビット）：MSSが有効かどうかを示します。
0: Disabled.
0：無効。
1: Enabled.
1：有効。
MRU (2 bytes): PPPoE local MRU (in bytes).
MRU（2バイト）：PPPoEローカルMRU（バイト単位）。
Magic-Number (4 bytes): Local magic number in PPP negotiation packets.
Magic-Number（4バイト）：PPPネゴシエーションパケットのローカルマジック番号。
Peer-Magic-Number (4 bytes): Remote peer magic number.
ピアマジックナンバー（4バイト）：リモートピアマジックナンバー。
Reserved: The Reserved fields MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The IPv4 Subscriber TLV is defined to carry IPv4-related information for a BNG user. It will be carried in an Update_Request message when IPv4 IPoE or PPPoE access is used.
IPv4サブスクライバーTLVは、BNGユーザーのIPv4関連情報を伝送するように定義されています。 IPv4 IPoEまたはPPPoEアクセスが使用されている場合、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway-IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 48: IPv4 Subscriber TLV
図48：IPv4サブスクライバーTLV
Where:
ただし：
TLV type: 4.
TLVタイプ：4。
TLV length: Variable.
TLVの長さ：可変。
User-ID (4 bytes): The identifier of a subscriber.
ユーザーID（4バイト）：サブスクライバーのID。
User-IPv4 (IPv4-Address): The IPv4 address of the subscriber.
User-IPv4（IPv4-Address）：サブスクライバーのIPv4アドレス。
Gateway-IPv4 (IPv4-Address): The gateway address of the subscriber.
Gateway-IPv4（IPv4-Address）：サブスクライバーのゲートウェイアドレス。
Portal-Force (P) (1 bit): Push advertisement.
Portal-Force（P）（1ビット）：プッシュ広告。
0: Off.
0：オフ。
1: On.
1：オン。
Web-Force (W) (1 bit): Push IPv4 Web.
Web-Force（W）（1ビット）：IPv4 Webをプッシュします。
0: Off.
0：オフ。
1: On.
1：オン。
Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo.
Echo-Enable（E）（1 bit）：UPはARP ReqまたはPPP Echoを返します。
0: Off.
0：オフ。
1: On.
1：オン。
IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) flag.
IPv4-URPF（U）（1ビット）：ユーザーユニキャストリバースパス転送（URPF）フラグ。
0: Off.
0：オフ。
1: On.
1：オン。
MTU (2 bytes): MTU value. The default value is 1500.
MTU（2バイト）：MTU値。デフォルト値は1500です。
VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.
VRF-Name Sub-TLV：サブスクライバーがどのVRFに属しているかを示します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The IPv6 Subscriber TLV is defined to carry IPv6-related information for a BNG user. It will be carried in an Update_Request message when IPv6 IPoE or PPPoE access is used.
IPv6サブスクライバーTLVは、BNGユーザーのIPv6関連情報を伝送するように定義されています。 IPv6 IPoEまたはPPPoEアクセスが使用されている場合、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User PD-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway ND-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Link-Local-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name Sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 49: IPv6 Subscriber TLV
図49：IPv6サブスクライバーTLV
Where:
ただし：
TLV type: 5.
TLVタイプ：5。
TLV length: Variable.
TLVの長さ：可変。
User-ID (4 bytes): The identifier of a subscriber.
ユーザーID（4バイト）：サブスクライバーのID。
User PD-Addresses (IPv6 Address List): Carries a list of Prefix Delegation (PD) addresses of the subscriber.
ユーザーPDアドレス（IPv6アドレスリスト）：サブスクライバーのプレフィックス委任（PD）アドレスのリストを保持します。
User ND-Addresses (IPv6 Address List): Carries a list of Neighbor Discovery (ND) addresses of the subscriber.
ユーザーNDアドレス（IPv6アドレスリスト）：サブスクライバーの近隣探索（ND）アドレスのリストを保持します。
User Link-Local-Address (IPv6-Address): The link-local address of the subscriber.
ユーザーリンクローカルアドレス（IPv6-アドレス）：サブスクライバーのリンクローカルアドレス。
IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface.
IPv6インターフェースID（8バイト）：IPv6インターフェースの識別子。
Portal-Force 1 bit (P): Push advertisement.
Portal-Force 1ビット（P）：プッシュ広告。
0: Off.
0：オフ。
1: On.
1：オン。
Web-Force 1 bit (W): Push IPv6 Web.
Web-Force 1ビット（W）：IPv6 Webをプッシュします。
0: Off.
0：オフ。
1: On.
1：オン。
Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo.
Echo-Enable 1ビット（E）：UPはARP ReqまたはPPP Echoを返します。
0: Off.
0：オフ。
1: On.
1：オン。
IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag.
IPv6-URPF 1ビット（U）：ユーザーリバースパス転送（URPF）フラグ。
0: Off.
0：オフ。
1: On.
1：オン。
MTU (2 bytes): The MTU value. The default value is 1500.
MTU（2バイト）：MTU値。デフォルト値は1500です。
VRF-Name Sub-TLV: Indicates the VRF to which the subscriber belongs.
VRF-Name Sub-TLV：サブスクライバーが属するVRFを示します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The IPv4 Static Subscriber Detect TLV is defined to carry IPv4-related information for a static access subscriber. It will be carried in an Update_Request message when IPv4 static access on a UP needs to be enabled.
IPv4静的サブスクライバー検出TLVは、静的アクセスサブスクライバーのIPv4関連情報を伝送するように定義されています。 UPでのIPv4スタティックアクセスを有効にする必要がある場合、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 50: IPv4 Static Subscriber TLV
図50：IPv4静的サブスクライバーTLV
Where:
ただし：
TLV type: 9.
TLVタイプ：9。
TLV length: Variable.
TLVの長さ：可変。
If-Index (4 bytes): The interface index of the interface from which the subscriber will dial-up.
If-Index（4バイト）：サブスクライバーがダイヤルアップするインターフェイスのインターフェイスインデックス。
C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. A valid value is 1-4094.
C-VID（VLAN-ID）：内部VLAN IDを示します。値0は、VLAN IDが無効であることを示します。有効な値は1〜4094です。
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that of the C-VID. A valid value is 1-4094.
P-VID（VLAN-ID）：外部VLAN IDを示します。値0は、VLAN IDが無効であることを示します。形式はC-VIDと同じです。有効な値は1〜4094です。
User Address (IPv4-Addr): The user's IPv4 address.
ユーザーアドレス（IPv4-Addr）：ユーザーのIPv4アドレス。
Gateway Address (IPv4-Addr): The gateway's IPv4 address.
ゲートウェイアドレス（IPv4-Addr）：ゲートウェイのIPv4アドレス。
User-MAC (MAC-Addr type): The MAC address of the subscriber.
User-MAC（MAC-Addrタイプ）：サブスクライバーのMACアドレス。
Sub-TLVs: The VRF-Name and If-Desc sub-TLVs may be carried.
サブTLV：VRF-NameおよびIf-DescサブTLVを伝送できます。
VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs.
VRF-Name sub-TLV：サブスクライバーが属するVRFを示します。
If-Desc sub-TLV: Carries the interface information.
If-Desc sub-TLV：インターフェース情報を伝達します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The IPv6 Static Subscriber Detect TLV is defined to carry IPv6-related information for a static access subscriber. It will be carried in an Update_Request message when needed to enable IPv6 static subscriber detection on a UP.
IPv6スタティックサブスクライバ検出TLVは、スタティックアクセスサブスクライバのIPv6関連情報を伝送するように定義されています。 UPでIPv6静的サブスクライバー検出を有効にする必要がある場合は、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 51: IPv6 Static Subscriber Detect TLV
図51：IPv6静的サブスクライバー検出TLV
Where:
ただし：
TLV type: 10.
TLVタイプ：10。
TLV length: Variable.
TLVの長さ：可変。
If-Index (4 bytes): The interface index of the interface from which the subscriber will dial-up.
If-Index（4バイト）：サブスクライバーがダイヤルアップするインターフェイスのインターフェイスインデックス。
C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 indicates that the VLAN ID is invalid. A valid value is 1-4094.
C-VID（VLAN-ID）：内部VLAN IDを示します。値0は、VLAN IDが無効であることを示します。有効な値は1〜4094です。
P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 indicates that the VLAN ID is invalid. The format is the same as that the of C-VID. A valid value is 1-4094.
P-VID（VLAN-ID）：外部VLAN IDを示します。値0は、VLAN IDが無効であることを示します。形式はC-VIDと同じです。有効な値は1〜4094です。
User Address (IPv6-Address type): The subscriber's IPv6 address.
ユーザーアドレス（IPv6-アドレスタイプ）：サブスクライバーのIPv6アドレス。
Gateway Address (IPv6-Address type): The gateway's IPv6 Address.
ゲートウェイアドレス（IPv6-アドレスタイプ）：ゲートウェイのIPv6アドレス。
User-MAC (MAC-Addr type): The MAC address of the subscriber.
User-MAC（MAC-Addrタイプ）：サブスクライバーのMACアドレス。
Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried
サブTLV：VRF-NameおよびIf-DescサブTLVを運ぶことができます
VRF-Name sub-TLV: Indicates the VRF to which the subscriber belongs.
VRF-Name sub-TLV：サブスクライバーが属するVRFを示します。
If-Desc sub-TLV: Carries the interface information.
If-Desc sub-TLV：インターフェース情報を伝達します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The L2TP-LAC Subscriber TLV is defined to carry the related information for an L2TP LAC access subscriber. It will be carried in an Update_Request message when L2TP LAC access is used.
L2TP-LACサブスクライバTLVは、L2TP LACアクセスサブスクライバの関連情報を伝送するように定義されています。 L2TP LACアクセスが使用される場合、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 52: L2TP-LAC Subscriber TLV
図52：L2TP-LACサブスクライバーTLV
Where:
ただし：
TLV type: 11.
TLVタイプ：11。
TLV length: 12 octets.
TLV長：12オクテット。
User-ID (4 bytes): The identifier of a user/subscriber.
ユーザーID（4バイト）：ユーザー/サブスクライバーのID。
Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
Local-Tunnel-ID（2バイト）：L2TPトンネルのローカルID。
Local-Session-ID (2 bytes): The local session ID with the L2TP tunnel.
Local-Session-ID（2バイト）：L2TPトンネルを使用したローカルセッションID。
Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at the remote endpoint.
Remote-Tunnel-ID（2バイト）：リモートエンドポイントのL2TPトンネルの識別子。
Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at the remote endpoint.
Remote-Session-ID（2バイト）：リモートエンドポイントのL2TPトンネルのセッションID。
The L2TP-LNS Subscriber TLV is defined to carry the related information for a L2TP LNS access subscriber. It will be carried in an Update_Request message when L2TP LNS access is used.
L2TP-LNSサブスクライバーTLVは、L2TP LNSアクセスサブスクライバーの関連情報を伝送するように定義されています。 L2TP LNSアクセスが使用される場合、Update_Requestメッセージで送信されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 53: L2TP-LNS Subscriber TLV
図53：L2TP-LNSサブスクライバーTLV
Where:
ただし：
TLV type: 12.
TLVタイプ：12。
TLV length: 12 octets.
TLV長：12オクテット。
User-ID (4 bytes): The identifier of a user/subscriber.
ユーザーID（4バイト）：ユーザー/サブスクライバーのID。
Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
Local-Tunnel-ID（2バイト）：L2TPトンネルのローカルID。
Local-Session-ID (2 bytes): The local session ID with the L2TP tunnel.
Local-Session-ID（2バイト）：L2TPトンネルを使用したローカルセッションID。
Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at the remote endpoint.
Remote-Tunnel-ID（2バイト）：リモートエンドポイントのL2TPトンネルの識別子。
Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at the remote endpoint.
Remote-Session-ID（2バイト）：リモートエンドポイントのL2TPトンネルのセッションID。
The L2TP-LAC Tunnel TLV is defined to carry information related to the L2TP LAC tunnel. It will be carried in the Update_Request message when L2TP LAC access is used.
L2TP-LACトンネルTLVは、L2TP LACトンネルに関連する情報を伝送するように定義されています。 L2TP LACアクセスが使用される場合、Update_Requestメッセージで伝達されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 54: L2TP-LAC Tunnel TLV
図54：L2TP-LACトンネルTLV
Where:
ただし：
TLV type: 13.
TLVタイプ：13。
TLV length: Variable.
TLVの長さ：可変。
Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
Local-Tunnel-ID（2バイト）：L2TPトンネルのローカルID。
Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.
Remote-Tunnel-ID（2バイト）：L2TPトンネルのリモートID。
Source-Port (2 bytes): The source UDP port number of an L2TP subscriber.
Source-Port（2バイト）：L2TPサブスクライバーのソースUDPポート番号。
Dest-Port (2 bytes): The destination UDP port number of an L2TP subscriber.
Dest-Port（2バイト）：L2TPサブスクライバーの宛先UDPポート番号。
Source-IP (IPv4/v6): The source IP address of the tunnel.
Source-IP（IPv4 / v6）：トンネルのソースIPアドレス。
Dest-IP (IPv4/v6): The destination IP address of the tunnel.
Dest-IP（IPv4 / v6）：トンネルの宛先IPアドレス。
VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel belongs.
VRF-Name Sub-TLV：L2TPサブスクライバートンネルが属するVRF名。
The L2TP-LNS Tunnel TLV is defined to carry information related to the L2TP LNS tunnel. It will be carried in the Update_Request message when L2TP LNS access is used.
L2TP-LNSトンネルTLVは、L2TP LNSトンネルに関連する情報を伝送するように定義されています。 L2TP LNSアクセスが使用される場合、Update_Requestメッセージに含まれます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 55: L2TP-LNS Tunnel TLV
図55：L2TP-LNSトンネルTLV
Where:
ただし：
TLV type: 14.
TLVタイプ：14。
TLV length: Variable.
TLVの長さ：可変。
Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.
Local-Tunnel-ID（2バイト）：L2TPトンネルのローカルID。
Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.
Remote-Tunnel-ID（2バイト）：L2TPトンネルのリモートID。
Source-Port (2 bytes): The source UDP port number of an L2TP subscriber.
Source-Port（2バイト）：L2TPサブスクライバーのソースUDPポート番号。
Dest-Port (2 bytes): The destination UDP port number of an L2TP subscriber.
Dest-Port（2バイト）：L2TPサブスクライバーの宛先UDPポート番号。
Source-IP (IPv4/v6): The source IP address of the tunnel.
Source-IP（IPv4 / v6）：トンネルのソースIPアドレス。
Dest-IP (IPv4/v6): The destination IP address of the tunnel.
Dest-IP（IPv4 / v6）：トンネルの宛先IPアドレス。
VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel belongs.
VRF-Name Sub-TLV：L2TPサブスクライバートンネルが属するVRF名。
The Update Response TLV is used to return the operation result of an update request. It is carried in the Update_Response message as a response to the Update_Request message.
更新応答TLVは、更新要求の操作結果を返すために使用されます。これは、Update_Requestメッセージへの応答としてUpdate_Responseメッセージで伝達されます。
The format of the value part of the Update Response TLV is as follows:
更新応答TLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Trans-ID | Oper-Code | Oper-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 56: Update Response TLV
図56：更新応答TLV
Where:
ただし：
TLV type: 302.
TLVタイプ：302。
TLV length: 12.
TLVの長さ：12。
User-ID (4 bytes): A unique identifier of a user/subscriber.
ユーザーID（4バイト）：ユーザー/サブスクライバーの固有ID。
User-Trans-ID (1 byte): In the case of dual-stack access or when modifying a session, User-Trans-ID is used to identify a user operation transaction. It is used by the CP to correlate a response to a specific request.
User-Trans-ID（1バイト）：デュアルスタックアクセスの場合、またはセッションを変更する場合、User-Trans-IDを使用してユーザー操作トランザクションを識別します。 CPは、応答を特定の要求に関連付けるために使用します。
Oper-Code (1 byte): Operation code.
Oper-Code（1バイト）：オペレーションコード。
1: Update.
1：更新。
2: Delete.
2：削除。
Oper-Result (1 byte): Operation Result.
Oper-Result（1バイト）：操作結果。
0: Success.
0：成功。
Others: Failure.
その他：失敗。
Error-Code (4 bytes): Operation failure cause code. For details, see Section 8.5.
エラーコード（4バイト）：操作失敗の原因コード。詳細については、8.5項を参照してください。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The Subscriber Policy TLV is used to carry the policies that will be applied to a subscriber. It is carried in the Update_Request message.
サブスクライバポリシーTLVは、サブスクライバに適用されるポリシーを伝達するために使用されます。 Update_Requestメッセージで伝達されます。
The format of the TLV value part is as follows:
TLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-Priority | E-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 57: Subscriber Policy TLV
図57：加入者ポリシーTLV
Where:
ただし：
TLV type: 6.
TLVタイプ：6。
TLV length: Variable.
TLVの長さ：可変。
User-ID (4 bytes): The identifier of a user/subscriber.
ユーザーID（4バイト）：ユーザー/サブスクライバーのID。
Ingress-Priority (1 byte): Indicates the upstream priority. The value range is 0~7.
Ingress-Priority（1 byte）：アップストリームの優先順位を示します。値の範囲は0〜7です。
Egress-Priority (1 byte): Indicates the downstream priority. The value range is 0~7.
Egress-Priority（1 byte）：ダウンストリームの優先順位を示します。値の範囲は0〜7です。
Sub-TLVs: The sub-TLVs that are present can occur in any order.
サブTLV：存在するサブTLVは任意の順序で発生します。
Ingress-CAR sub-TLV: Upstream CAR.
Ingress-CAR sub-TLV：Upstream CAR。
Egress-CAR sub-TLV: Downstream CAR.
Egress-CAR sub-TLV：ダウンストリームCAR。
Ingress-QoS-Profile sub-TLV: Indicates the name of the QoS-Profile that is the profile in the upstream direction.
Ingress-QoS-Profile sub-TLV：アップストリーム方向のプロファイルであるQoS-Profileの名前を示します。
Egress-QoS-Profile sub-TLV: Indicates the name of the QoS-Profile that is the profile in the downstream direction.
Egress-QoS-Profile sub-TLV：ダウンストリーム方向のプロファイルであるQoS-Profileの名前を示します。
User-ACL-Policy sub-TLV: All ACL user policies, including v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, v4SpecialACL, and v6SpecialACL.
User-ACL-Policy sub-TLV：v4ACLIN、v4ACLOUT、v6ACLIN、v6ACLOUT、v4WEBACL、v6WEBACL、v4SpecialACL、v6SpecialACLを含むすべてのACLユーザーポリシー。
Multicast-Profile4 sub-TLV: IPv4 multicast policy name.
Multicast-Profile4 sub-TLV：IPv4マルチキャストポリシー名。
Multicast-Profile6 sub-TLV: IPv6 multicast policy name.
Multicast-Profile6 sub-TLV：IPv6マルチキャストポリシー名。
NAT-Instance sub-TLV: Indicates the instance ID of a NAT user.
NAT-Instance sub-TLV：NATユーザーのインスタンスIDを示します。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The Subscriber CGN Port Range TLV is used to carry the NAT public address and port range. It will be carried in the Update_Response message when CGN is used.
サブスクライバCGNポート範囲TLVは、NATパブリックアドレスとポート範囲を伝達するために使用されます。 CGNが使用されている場合、Update_Responseメッセージで送信されます。
The format of the value part of this TLV is as follows:
このTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Port-Start | NAT-Port-End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 58: Subscriber CGN Port Range TLV
図58：サブスクライバーCGNポート範囲TLV
Where:
ただし：
TLV type: 15.
TLVタイプ：15。
TLV length: 12 octets.
TLV長：12オクテット。
User-ID (4 bytes): The identifier of a user/subscriber.
ユーザーID（4バイト）：ユーザー/サブスクライバーのID。
NAT-Port-Start (2 bytes): The start port number.
NAT-Port-Start（2バイト）：開始ポート番号。
NAT-Port-End (2 bytes): The end port number.
NAT-Port-End（2バイト）：終了ポート番号。
NAT-Address (4 bytes): The NAT public network address.
NAT-Address（4バイト）：NATパブリックネットワークアドレス。
The TLVs in this section are for reporting interface and board-level information from the UP to the CP.
このセクションのTLVは、UPからCPへのインターフェースおよびボードレベルの情報を報告するためのものです。
The Interface Status TLV is used to carry the status information of an interface on a UP. It is carried in a Report message.
インターフェイスステータスTLVは、UP上のインターフェイスのステータス情報を伝えるために使用されます。レポートメッセージで伝達されます。
The format of the value part of this TLV is as follows:
このTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-Address (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-Address (lower part) | Phy-State | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 59: Interface Status TLV
図59：インターフェイスステータスTLV
Where:
ただし：
TLV type: 200.
TLVタイプ：200。
TLV length: Variable.
TLVの長さ：可変。
If-Index (4 bytes): Indicates the interface index.
If-Index（4バイト）：インターフェースのインデックスを示します。
MAC-Address (MAC-Addr type): Interface MAC address.
MAC-Address（MAC-Addr type）：インターフェースMACアドレス。
Phy-State (1 byte): Physical status of the interface.
Phy-State（1バイト）：インターフェースの物理ステータス。
0: Down.
0：ダウン。
1: Up.
1アップ。
MTU (4 bytes): Interface MTU value.
MTU（4バイト）：インターフェースMTU値。
Sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried.
サブTLV：If-DescおよびVRF-NameサブTLVを伝送できます。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The Board Status TLV is used to carry the status information of a board on an UP. It is carried in a Report message.
ボードステータスTLVは、UP上のボードのステータス情報を伝えるために使用されます。レポートメッセージで伝達されます。
The format of the value part of the Board Status TLV is as follows:
ボードステータスTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board-Type | Board-State | Reserved | Chassis |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot | Sub-Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 60: Board Status TLV
図60：ボードステータスTLV
Where:
ただし：
TLV type: 201.
TLVタイプ：201。
TLV length: 8 octets.
TLV長：8オクテット。
Chassis (1 byte): The chassis number of the board.
シャーシ（1バイト）：ボードのシャーシ番号。
Slot (16 bits): The slot number of the board.
スロット（16ビット）：ボードのスロット番号。
Sub-Slot (16 bits): The sub-slot number of the board.
サブスロット（16ビット）：ボードのサブスロット番号。
Board-Type (1 byte): The type of board used.
ボードタイプ（1バイト）：使用されているボードのタイプ。
1: CGN Service Process Unit (SPU) board.
1：CGNサービスプロセスユニット（SPU）ボード。
2: Line Process Unit (LPU) board.
2：ラインプロセスユニット（LPU）ボード。
Board-State (1 byte): Indicates whether there are issues with the board.
ボード状態（1バイト）：ボードに問題があるかどうかを示します。
0: Normal.
0：通常。
1: Abnormal.
1：異常。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The Address Allocation Request TLV is used to request address allocation from the CP. A Pool-Name sub-TLV is carried to indicate from which address pool to allocate addresses. The Address Allocation Request TLV is carried in the Addr_Allocation_Req message.
アドレス割り当て要求TLVは、CPからのアドレス割り当てを要求するために使用されます。 Pool-NameサブTLVは、どのアドレスプールからアドレスを割り当てるかを示すために使用されます。アドレス割り当て要求TLVは、Addr_Allocation_Reqメッセージで伝達されます。
The format of the value part of this TLV is as follows:
このTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 61: Address Allocation Request TLV
図61：アドレス割り当て要求TLV
Where:
ただし：
TLV type: 400.
TLVタイプ：400。
TLV length: Variable.
TLVの長さ：可変。
Pool-Name sub-TLV: Indicates from which address pool to allocate address.
Pool-Name sub-TLV：アドレスを割り当てるアドレスプールを示します。
The Address Allocation Response TLV is used to return the address allocation result; it is carried in the Addr_Allocation_Ack message.
アドレス割り当て応答TLVは、アドレス割り当て結果を返すために使用されます。 Addr_Allocation_Ackメッセージで伝達されます。
The value part of the Address Allocation Response TLV is formatted as follows:
アドレス割り当て応答TLVの値の部分は、次のようにフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 62: Address Allocation Response TLV
図62：アドレス割り当て応答TLV
Where:
ただし：
TLV type: 401.
TLVタイプ：401。
TLV length: Variable.
TLVの長さ：可変。
Lease Time (4 bytes): Duration of address lease in seconds.
リース時間（4バイト）：アドレスのリース期間（秒単位）。
Client-IP (IPv4-Address type): The allocated IPv4 address and mask.
クライアントIP（IPv4-アドレスタイプ）：割り当てられたIPv4アドレスとマスク。
Error-Code (4 bytes): Indicates success or an error.
エラーコード（4バイト）：成功またはエラーを示します。
0: Success.
0：成功。
1: Failure.
1：失敗。
3001: Pool-Mismatch. The corresponding address pool cannot be found.
3001：プールの不一致。対応するアドレスプールが見つかりません。
3002: Pool-Full. The address pool is fully allocated, and no address segment is available.
3002：プールがいっぱいです。アドレスプールは完全に割り当てられており、使用可能なアドレスセグメントはありません。
Pool-Name sub-TLV: Indicates from which address pool the address is allocated.
Pool-Name sub-TLV：アドレスが割り当てられているアドレスプールを示します。
The Address Renewal Request TLV is used to request address renewal from the CP. It is carried in the Addr_Renew_Req message.
アドレス更新要求TLVは、CPからアドレス更新を要求するために使用されます。 Addr_Renew_Reqメッセージで伝達されます。
The format of this TLV value is as follows:
このTLV値の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 63: Address Renewal Request TLV
図63：アドレス更新要求TLV
Where:
ただし：
TLV type: 402.
TLVタイプ：402。
TLV length: Variable.
TLVの長さ：可変。
Client-IP (IPv4-Address type): The IPv4 address and mask to be renewed.
クライアントIP（IPv4-アドレスタイプ）：更新するIPv4アドレスとマスク。
Pool-Name sub-TLV: Indicates from which address pool to renew the address.
Pool-Name sub-TLV：アドレスを更新するアドレスプールを示します。
The Address Renewal Response TLV is used to return the address renewal result. It is carried in the Addr_Renew_Ack message.
アドレス更新応答TLVは、アドレス更新結果を返すために使用されます。 Addr_Renew_Ackメッセージで伝達されます。
The format of this TLV value is as follows:
このTLV値の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 64: Address Renewal Response TLV
図64：アドレス更新応答TLV
Where:
ただし：
TLV type: 403.
TLVタイプ：403。
TLV length: Variable.
TLVの長さ：可変。
Client-IP (IPv4-Address type): The renewed IPv4 address and mask.
クライアントIP（IPv4-アドレスタイプ）：更新されたIPv4アドレスとマスク。
Error-Code (4 bytes): Indicates success or an error:
エラーコード（4バイト）：成功またはエラーを示します。
0: Success.
0：成功。
1: Failure.
1：失敗。
3001: Pool-Mismatch. The corresponding address pool cannot be found.
3001：プールの不一致。対応するアドレスプールが見つかりません。
3002: Pool-Full. The address pool is fully allocated, and no address segment is available.
3002：プールがいっぱいです。アドレスプールは完全に割り当てられており、使用可能なアドレスセグメントはありません。
3003: Subnet-Mismatch. The address pool subnet cannot be found.
3003：サブネットの不一致。アドレスプールサブネットが見つかりません。
3004: Subnet-Conflict. Subnets in the address pool have been assigned to other clients.
3004：サブネットの競合。アドレスプール内のサブネットが他のクライアントに割り当てられています。
Pool-Name sub-TLV: Indicates from which address pool to renew the address.
Pool-Name sub-TLV：アドレスを更新するアドレスプールを示します。
The Address Release Request TLV is used to release an IPv4 address. It is carried in the Addr_Release_Req message.
アドレス解放要求TLVは、IPv4アドレスを解放するために使用されます。 Addr_Release_Reqメッセージで伝達されます。
The value part of this TLV is formatted as follows:
このTLVの値の部分は、次のようにフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 65: Address Release Request TLV
図65：アドレス解放要求TLV
Where:
ただし：
TLV type: 404.
TLVタイプ：404。
TLV length: Variable.
TLVの長さ：可変。
Client-IP (IPv4-Address type): The IPv4 address and mask to be released.
Client-IP（IPv4-Addressタイプ）：解放されるIPv4アドレスとマスク。
Pool-Name sub-TLV: Indicates from which address pool to release the address.
Pool-Name sub-TLV：どのアドレスプールからアドレスを解放するかを示します。
The Address Release Response TLV is used to return the address release result. It is carried in the Addr_Release_Ack message.
アドレス解放応答TLVは、アドレス解放結果を返すために使用されます。 Addr_Release_Ackメッセージで伝達されます。
The format of the value part of this TLV is as follows:
このTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 66: Address Release Response TLV
図66：アドレス解放応答TLV
Where:
ただし：
TLV type: 405.
TLVタイプ：405。
TLV length: Variable.
TLVの長さ：可変。
Client-IP (IPv4-Address type): The released IPv4 address and mask.
クライアントIP（IPv4-アドレスタイプ）：リリースされたIPv4アドレスとマスク。
Error-Code (4 bytes): Indicates success or an error.
エラーコード（4バイト）：成功またはエラーを示します。
0: Success. Address release success.
0：成功。リリースの成功に対処します。
1: Failure. Address release failed.
1：失敗。アドレスの解放に失敗しました。
3001: Pool-Mismatch. The corresponding address pool cannot be found.
3001：プールの不一致。対応するアドレスプールが見つかりません。
3003: Subnet-Mismatch. The address cannot be found.
3003：サブネットの不一致。住所が見つかりません。
3004: Subnet-Conflict. The address has been allocated to another subscriber.
3004：サブネットの競合。アドレスは別のサブスクライバーに割り当てられています。
Pool-Name sub-TLV: Indicates from which address pool to release the address.
Pool-Name sub-TLV：どのアドレスプールからアドレスを解放するかを示します。
The Subscriber Traffic Statistics TLV is used to return the traffic statistics of a user/subscriber. The format of the value part of this TLV is as follows:
サブスクライバートラフィック統計TLVは、ユーザー/サブスクライバーのトラフィック統計を返すために使用されます。このTLVの値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 67: Subscriber Traffic Statistics TLV
図67：加入者トラフィック統計TLV
Where:
ただし：
TLV type: 300.
TLVタイプ：300。
TLV length: 72 octets.
TLV長：72オクテット。
User-ID (4 bytes): The subscriber identifier.
ユーザーID（4バイト）：サブスクライバーID。
Statistics-Type (4 bytes): Traffic type. It can be one of the following options:
統計タイプ（4バイト）：トラフィックタイプ。次のオプションのいずれかになります。
0: IPv4 traffic.
0：IPv4トラフィック。
1: IPv6 traffic.
1：IPv6トラフィック。
2: Dual-stack traffic.
2：デュアルスタックトラフィック。
Ingress Packets (8 bytes): The number of the packets in the upstream direction.
入力パケット（8バイト）：アップストリーム方向のパケット数。
Ingress Bytes (8 bytes): The bytes of the upstream traffic.
入力バイト（8バイト）：アップストリームトラフィックのバイト。
Ingress Loss Packets (8 bytes): The number of the lost packets in the upstream direction.
Ingress Loss Packets（8バイト）：アップストリーム方向の失われたパケットの数。
Ingress Loss Bytes (8 bytes): The bytes of the lost upstream packets.
Ingress Loss Bytes（8 bytes）：失われたアップストリームパケットのバイト。
Egress Packets (8 bytes): The number of the packets in the downstream direction.
出力パケット（8バイト）：ダウンストリーム方向のパケット数。
Egress Bytes (8 bytes): The bytes of the downstream traffic.
出力バイト（8バイト）：ダウンストリームトラフィックのバイト。
Egress Loss Packets (8 bytes): The number of the lost packets in the downstream direction.
Egress Loss Packets（8バイト）：ダウンストリーム方向の失われたパケットの数。
Egress Loss Bytes (8 bytes): The bytes of the lost downstream packets.
Egress Loss Bytes（8 bytes）：失われたダウンストリームパケットのバイト。
The Subscriber Detection Result TLV is used to return the detection result of a subscriber. Subscriber detection is a function to detect whether or not a subscriber is online. The result can be used by the CP to determine how to deal with the subscriber session (e.g., delete the session if detection failed).
サブスクライバ検出結果TLVは、サブスクライバの検出結果を返すために使用されます。サブスクライバー検出は、サブスクライバーがオンラインかどうかを検出する機能です。 CPはその結果を使用して、サブスクライバーセッションの処理方法を決定できます（たとえば、検出に失敗した場合はセッションを削除します）。
The format of this TLV value part is as follows:
このTLV値の部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect-Type | Detect-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 68: Subscriber Detection Result TLV
図68：加入者検出結果TLV
Where:
ただし：
TLV type: 301.
TLVタイプ：301。
TLV length: 8 octets.
TLV長：8オクテット。
User-ID (4 bytes): The subscriber identifier.
ユーザーID（4バイト）：サブスクライバーID。
Detect-Type (1 byte): Type of traffic detected.
Detect-Type（1バイト）：検出されたトラフィックのタイプ。
0: IPv4 detection.
0：IPv4検出。
1: IPv6 detection.
1：IPv6検出。
2: PPP detection.
2：PPP検出。
Detect-Result (1 byte): Indicates whether the detection was successful.
Detect-Result（1 byte）：検出が成功したかどうかを示します。
0: Indicates that the detection is successful.
0：検出が成功したことを示します。
1: Detection failure. The UP needs to report only when the detection fails.
1：検出失敗。 UPは、検出が失敗した場合にのみレポートする必要があります。
Reserved: The Reserved field MUST be sent as zero and ignored on receipt.
予約済み：予約済みフィールドはゼロとして送信され、受信時に無視される必要があります。
The Vendor TLV occurs as the first TLV in the Vendor message (Section 6.6). It provides a Sub-Type that effectively extends the message type in the message header, provides for versioning of vendor TLVs, and can accommodate sub-TLVs.
ベンダーTLVは、ベンダーメッセージ（セクション6.6）の最初のTLVとして発生します。メッセージヘッダーのメッセージタイプを効果的に拡張するサブタイプを提供し、ベンダーTLVのバージョン管理を提供し、サブTLVに対応できます。
The value part of the Vendor TLV is formatted as follows:
ベンダーTLVの値の部分は、次のようにフォーマットされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 69: Vendor TLV
図69：ベンダーTLV
Where:
ただし：
TLV type: 1024.
TLVタイプ：1024。
TLV length: Variable.
TLVの長さ：可変。
Vendor-ID (4 bytes): Vendor ID as defined in RADIUS [RFC2865].
ベンダーID（4バイト）：RADIUS [RFC2865]で定義されているベンダーID。
Sub-Type (2 bytes): Used by the vendor to distinguish multiple different vendor messages.
サブタイプ（2バイト）：複数の異なるベンダーメッセージを区別するためにベンダーによって使用されます。
Sub-Type-Version (2 bytes): Used by the vendor to distinguish different versions of a vendor-defined message Sub-Type.
サブタイプバージョン（2バイト）：ベンダー定義のメッセージサブタイプの異なるバージョンを区別するためにベンダーによって使用されます。
Sub-TLVs (variable): Sub-TLVs as specified by the vendor.
サブTLV（変数）：ベンダーが指定したサブTLV。
Since vendor code will be handling the TLV after the Vendor-ID field is recognized, the remainder of the TLV values can be organized however the vendor wants. But it is desirable for a vendor to be able to define multiple different vendor messages and to keep track of different versions of its vendor-defined messages. Thus, it is RECOMMENDED that the vendor assign a Sub-Type value for each vendor message that it defines different from other Sub-Type values that vendor has used. Also, when modifying a vendor-defined message in a way potentially incompatible with a previous definition, the vendor SHOULD increase the value it is using in the Sub-Type-Version field.
Vendor-IDフィールドが認識された後、ベンダーコードがTLVを処理するため、ベンダーが望む方法で、残りのTLV値を編成できます。ただし、ベンダーが複数の異なるベンダーメッセージを定義し、ベンダー定義のメッセージの異なるバージョンを追跡できることが望ましいです。したがって、ベンダーが定義した各ベンダーメッセージに、ベンダーが使用した他のサブタイプ値とは異なるサブタイプ値を割り当てることをお勧めします。また、ベンダー定義のメッセージを以前の定義と互換性がない可能性がある方法で変更する場合、ベンダーはSub-Type-Versionフィールドで使用している値を増やす必要があります（SHOULD）。
This section provides tables of the S-CUSP codepoints, particularly message types, TLV types, TLV operation codes, sub-TLV types, and error codes. In most cases, references are provided to relevant sections elsewhere in this document.
このセクションでは、S-CUSPコードポイント、特にメッセージタイプ、TLVタイプ、TLVオペレーションコード、サブTLVタイプ、エラーコードの表を示します。ほとんどの場合、参照はこのドキュメントの他の場所にある関連セクションに提供されています。
+---------+---------------------+--------------------------+
| Type | Name | Section of This Document |
+=========+=====================+==========================+
| 0 | Reserved | |
+---------+---------------------+--------------------------+
| 1 | Hello | 6.2.1 |
+---------+---------------------+--------------------------+
| 2 | Keepalive | 6.2.2 |
+---------+---------------------+--------------------------+
| 3 | Sync_Request | 6.2.3 |
+---------+---------------------+--------------------------+
| 4 | Sync_Begin | 6.2.4 |
+---------+---------------------+--------------------------+
| 5 | Sync_Data | 6.2.5 |
+---------+---------------------+--------------------------+
| 6 | Sync_End | 6.2.6 |
+---------+---------------------+--------------------------+
| 7 | Update_Request | 6.2.7 |
+---------+---------------------+--------------------------+
| 8 | Update_Response | 6.2.8 |
+---------+---------------------+--------------------------+
| 9 | Report | 6.4 |
+---------+---------------------+--------------------------+
| 10 | Event | 6.3 |
+---------+---------------------+--------------------------+
| 11 | Vendor | 6.6 |
+---------+---------------------+--------------------------+
| 12 | Error | 6.7 |
+---------+---------------------+--------------------------+
| 13-199 | Unassigned | |
+---------+---------------------+--------------------------+
| 200 | Addr_Allocation_Req | 6.5.1 |
+---------+---------------------+--------------------------+
| 201 | Addr_Allocation_Ack | 6.5.2 |
+---------+---------------------+--------------------------+
| 202 | Addr_Renew_Req | 6.5.3 |
+---------+---------------------+--------------------------+
| 203 | Addr_Renew_Ack | 6.5.4 |
+---------+---------------------+--------------------------+
| 204 | Addr_Release_Req | 6.5.5 |
+---------+---------------------+--------------------------+
| 205 | Addr_Release_Ack | 6.5.6 |
+---------+---------------------+--------------------------+
| 206-254 | Unassigned | |
+---------+---------------------+--------------------------+
| 255 | Reserved | |
+---------+---------------------+--------------------------+
Table 5: Message Types
表5：メッセージタイプ
+-----------+-------------+-----------------------------------+
| Type | Name | Usage Description |
+===========+=============+===================================+
| 0 | Reserved | - |
+-----------+-------------+-----------------------------------+
| 1 | BAS | Carries the BNG access functions |
| | Function | to be enabled or disabled on |
| | | specified interfaces. |
+-----------+-------------+-----------------------------------+
| 2 | Basic | Carries the basic information |
| | Subscriber | about a BNG subscriber. |
+-----------+-------------+-----------------------------------+
| 3 | PPP | Carries the PPP information about |
| | Subscriber | a BNG subscriber. |
+-----------+-------------+-----------------------------------+
| 4 | IPv4 | Carries the IPv4 address of a BNG |
| | Subscriber | subscriber. |
+-----------+-------------+-----------------------------------+
| 5 | IPv6 | Carries the IPv6 address of a BNG |
| | Subscriber | subscriber. |
+-----------+-------------+-----------------------------------+
| 6 | Subscriber | Carries the policy information |
| | Policy | applied to a BNG subscriber. |
+-----------+-------------+-----------------------------------+
| 7 | IPv4 | Carries the IPv4 network routing |
| | Routing | information. |
+-----------+-------------+-----------------------------------+
| 8 | IPv6 | Carries the IPv6 network routing |
| | Routing | information. |
+-----------+-------------+-----------------------------------+
| 9 | IPv4 Static | Carries the IPv4 static |
| | Subscriber | subscriber detect information. |
| | Detect | |
+-----------+-------------+-----------------------------------+
| 10 | IPv6 Static | Carries the IPv6 static |
| | Subscriber | subscriber detect information. |
| | Detect | |
+-----------+-------------+-----------------------------------+
| 11 | L2TP-LAC | Carries the L2TP LAC subscriber |
| | Subscriber | information. |
+-----------+-------------+-----------------------------------+
| 12 | L2TP-LNS | Carries the L2TP LNS subscriber |
| | Subscriber | information. |
+-----------+-------------+-----------------------------------+
| 13 | L2TP-LAC | Carries the L2TP LAC tunnel |
| | Tunnel | subscriber information. |
+-----------+-------------+-----------------------------------+
| 14 | L2TP-LNS | Carries the L2TP LNS tunnel |
| | Tunnel | subscriber information. |
+-----------+-------------+-----------------------------------+
| 15 | Subscriber | Carries the public IPv4 address |
| | CGN Port | and related port range of a BNG |
| | Range | subscriber. |
+-----------+-------------+-----------------------------------+
| 16-99 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 100 | Hello | Used for version and Keepalive |
| | | timers negotiation. |
+-----------+-------------+-----------------------------------+
| 101 | Error | Carried in the Ack of the control |
| | Information | message. Carries the processing |
| | | result, success, or error. |
+-----------+-------------+-----------------------------------+
| 102 | Keepalive | Carried in the Hello message for |
| | | Keepalive timers negotiation. |
+-----------+-------------+-----------------------------------+
| 103-199 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 200 | Interface | Interfaces status reported by the |
| | Status | UP including physical interfaces, |
| | | sub-interfaces, trunk interfaces, |
| | | and tunnel interfaces. |
+-----------+-------------+-----------------------------------+
| 201 | Board | Board information reported by the |
| | Status | UP including the board type and |
| | | in-position status. |
+-----------+-------------+-----------------------------------+
| 202-299 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 300 | Subscriber | User traffic statistics. |
| | Traffic | |
| | Statistics | |
+-----------+-------------+-----------------------------------+
| 301 | Subscriber | User detection information. |
| | Detection | |
| | Result | |
+-----------+-------------+-----------------------------------+
| 302 | Update | The processing result of a |
| | Response | subscriber session update. |
+-----------+-------------+-----------------------------------+
| 303-299 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 400 | Address | Request address allocation. |
| | Allocation | |
| | Request | |
+-----------+-------------+-----------------------------------+
| 401 | Address | Address allocation response. |
| | Allocation | |
| | Response | |
+-----------+-------------+-----------------------------------+
| 402 | Address | Request for address lease |
| | Renewal | renewal. |
| | Request | |
+-----------+-------------+-----------------------------------+
| 403 | Address | Response to a request for |
| | Renewal | extending an IP address lease. |
| | Response | |
+-----------+-------------+-----------------------------------+
| 404 | Address | Request to release the address. |
| | Release | |
| | Request | |
+-----------+-------------+-----------------------------------+
| 405 | Address | Ack of a message releasing an IP |
| | Release | address. |
| | Response | |
+-----------+-------------+-----------------------------------+
| 406-1023 | Unassigned | - |
+-----------+-------------+-----------------------------------+
| 1024 | Vendor | As implemented by the vendor. |
+-----------+-------------+-----------------------------------+
| 1039-4095 | Unassigned | - |
+-----------+-------------+-----------------------------------+
Table 6: TLV Types
表6：TLVタイプ
TLV operation codes appear in the Oper field in the header of some TLVs. See Section 7.1.
TLVオペレーションコードは、一部のTLVのヘッダーのOperフィールドに表示されます。セクション7.1を参照してください。
+------+------------+
| Code | Operation |
+======+============+
| 0 | Reserved |
+------+------------+
| 1 | Update |
+------+------------+
| 2 | Delete |
+------+------------+
| 3-15 | Unassigned |
+------+------------+
Table 7: TLV Operation Codes
表7：TLVオペレーションコード
See Section 7.3.
セクション7.3を参照してください。
+----------+---------------------+--------------------------+
| Type | Name | Section of This Document |
+==========+=====================+==========================+
| 0 | Reserved | |
+----------+---------------------+--------------------------+
| 1 | VRF Name | 7.3.1 |
+----------+---------------------+--------------------------+
| 2 | Ingress-QoS-Profile | 7.3.1 |
+----------+---------------------+--------------------------+
| 3 | Egress-QoS-Profile | 7.3.1 |
+----------+---------------------+--------------------------+
| 4 | User-ACL-Policy | 7.3.1 |
+----------+---------------------+--------------------------+
| 5 | Multicast-ProfileV4 | 7.3.1 |
+----------+---------------------+--------------------------+
| 6 | Multicast-ProfileV6 | 7.3.1 |
+----------+---------------------+--------------------------+
| 7 | Ingress-CAR | 7.3.2 |
+----------+---------------------+--------------------------+
| 8 | Egress-CAR | 7.3.3 |
+----------+---------------------+--------------------------+
| 9 | NAT-Instance | 7.3.1 |
+----------+---------------------+--------------------------+
| 10 | Pool-Name | 7.3.1 |
+----------+---------------------+--------------------------+
| 11 | If-Desc | 7.3.4 |
+----------+---------------------+--------------------------+
| 12 | IPv6-Address List | 7.3.5 |
+----------+---------------------+--------------------------+
| 13 | Vendor | 7.3.6 |
+----------+---------------------+--------------------------+
| 12-64534 | Unassigned | |
+----------+---------------------+--------------------------+
| 65535 | Reserved | |
+----------+---------------------+--------------------------+
Table 8: Sub-TLV Types
表8：サブTLVタイプ
+-----------------+-----------------------+-------------------------+
| Value | Name | Remarks |
+=================+=======================+=========================+
| 0 | Success | Success |
+-----------------+-----------------------+-------------------------+
| 1 | Failure | Malformed message |
| | | received. |
+-----------------+-----------------------+-------------------------+
| 2 | TLV-Unknown | One or more of the |
| | | TLVs was not |
| | | understood. |
+-----------------+-----------------------+-------------------------+
| 3 | TLV-Length | The TLV length is |
| | | abnormal. |
+-----------------+-----------------------+-------------------------+
| 4-999 | Unassigned | Unassigned basic |
| | | error codes. |
+-----------------+-----------------------+-------------------------+
| 1000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 1001 | Version-Mismatch | The version |
| | | negotiation fails. |
| | | Terminate. The |
| | | subsequent service |
| | | processes |
| | | corresponding to the |
| | | UP are suspended. |
+-----------------+-----------------------+-------------------------+
| 1002 | Keepalive Error | The keepalive |
| | | negotiation fails. |
+-----------------+-----------------------+-------------------------+
| 1003 | Timer Expires | The establishment |
| | | timer expired. |
+-----------------+-----------------------+-------------------------+
| 1004-1999 | Unassigned | Unassigned error |
| | | codes for version |
| | | negotiation. |
+-----------------+-----------------------+-------------------------+
| 2000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 2001 | Synch-NoReady | The data to be |
| | | smoothed is not |
| | | ready. |
+-----------------+-----------------------+-------------------------+
| 2002 | Synch-Unsupport | The request for |
| | | smooth data is not |
| | | supported. |
+-----------------+-----------------------+-------------------------+
| 2003-2999 | Unassigned | Unassigned data |
| | | synchronization |
| | | error codes. |
+-----------------+-----------------------+-------------------------+
| 3000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 3001 | Pool-Mismatch | The corresponding |
| | | address pool cannot |
| | | be found. |
+-----------------+-----------------------+-------------------------+
| 3002 | Pool-Full | The address pool is |
| | | fully allocated, and |
| | | no address segment |
| | | is available. |
+-----------------+-----------------------+-------------------------+
| 3003 | Subnet-Mismatch | The address pool |
| | | subnet cannot be |
| | | found. |
+-----------------+-----------------------+-------------------------+
| 3004 | Subnet-Conflict | Subnets in the |
| | | address pool have |
| | | been classified into |
| | | other clients. |
+-----------------+-----------------------+-------------------------+
| 3005-3999 | Unassigned | Unassigned error |
| | | codes for address |
| | | allocation. |
+-----------------+-----------------------+-------------------------+
| 4000 | Reserved | |
+-----------------+-----------------------+-------------------------+
| 4001 | Update-Fail-No-Res | The forwarding table |
| | | fails to be |
| | | delivered because |
| | | the forwarding |
| | | resources are |
| | | insufficient. |
+-----------------+-----------------------+-------------------------+
| 4002 | QoS-Update-Success | The QoS policy takes |
| | | effect. |
+-----------------+-----------------------+-------------------------+
| 4003 | QoS-Update-Sq-Fail | Failed to process |
| | | the queue in the QoS |
| | | policy. |
+-----------------+-----------------------+-------------------------+
| 4004 | QoS-Update-CAR-Fail | Processing of the |
| | | CAR in the QoS |
| | | policy fails. |
+-----------------+-----------------------+-------------------------+
| 4005 | Statistic-Fail-No-Res | Statistics |
| | | processing failed |
| | | due to insufficient |
| | | statistics |
| | | resources. |
+-----------------+-----------------------+-------------------------+
| 4006-4999 | Unassigned | Unassigned |
| | | forwarding table |
| | | delivery error |
| | | codes. |
+-----------------+-----------------------+-------------------------+
| 5000-4294967295 | Reserved | |
+-----------------+-----------------------+-------------------------+
Table 9: Error Codes
表9：エラーコード
Defined values of the If-Type field in the If-Desc sub-TLV (see Section 7.3.4) are as follows:
If-DescサブTLV（セクション7.3.4を参照）のIf-Typeフィールドの定義値は次のとおりです。
+-------+--------------------+
| Value | Meaning |
+=======+====================+
| 0 | Reserved |
+-------+--------------------+
| 1 | Fast Ethernet (FE) |
+-------+--------------------+
| 2 | GE |
+-------+--------------------+
| 3 | 10GE |
+-------+--------------------+
| 4 | 100GE |
+-------+--------------------+
| 5 | Eth-Trunk |
+-------+--------------------+
| 6 | Tunnel |
+-------+--------------------+
| 7 | VE |
+-------+--------------------+
| 8-254 | Unassigned |
+-------+--------------------+
| 255 | Reserved |
+-------+--------------------+
Table 10: If-Type Values
表10：If-Type値
Defined values of the Access-Mode field in the BAS Function TLV (see Section 7.7) are as follows:
BAS Function TLV（セクション7.7を参照）のAccess-Modeフィールドの定義値は次のとおりです。
+-------+---------------------+
| Value | Meaning |
+=======+=====================+
| 0 | Layer 2 subscriber |
+-------+---------------------+
| 1 | Layer 3 subscriber |
+-------+---------------------+
| 2 | Layer 2 leased line |
+-------+---------------------+
| 3 | Layer 3 leased line |
+-------+---------------------+
| 4-254 | Unassigned |
+-------+---------------------+
| 255 | Reserved |
+-------+---------------------+
Table 11: Access-Mode Values
表11：アクセスモードの値
Defined values of the Auth-Method4 and Auth-Method6 fields in the BAS Function TLV (see Section 7.7) are defined as bit fields as follows:
BAS Function TLV（セクション7.7を参照）のAuth-Method4およびAuth-Method6フィールドの定義された値は、次のようにビットフィールドとして定義されます。
+------+-------------------------+
| Bit | Meaning |
+======+=========================+
| 0x01 | PPPoE authentication |
+------+-------------------------+
| 0x02 | DOT1X authentication |
+------+-------------------------+
| 0x04 | Web authentication |
+------+-------------------------+
| 0x08 | Web fast authentication |
+------+-------------------------+
| 0x10 | Binding authentication |
+------+-------------------------+
| 0x20 | Reserved |
+------+-------------------------+
| 0x40 | Reserved |
+------+-------------------------+
| 0x80 | Reserved |
+------+-------------------------+
Table 12: Auth-Method4 Values
表12：Auth-Method4の値
+------+-------------------------+
| Bit | Meaning |
+======+=========================+
| 0x01 | PPPoE authentication |
+------+-------------------------+
| 0x02 | DOT1X authentication |
+------+-------------------------+
| 0x04 | Web authentication |
+------+-------------------------+
| 0x08 | Web fast authentication |
+------+-------------------------+
| 0x10 | Binding authentication |
+------+-------------------------+
| 0x20 | Reserved |
+------+-------------------------+
| 0x40 | Reserved |
+------+-------------------------+
| 0x80 | Reserved |
+------+-------------------------+
Table 13: Auth-Method6 Values
表13：Auth-Method6の値
Values of the Route-Type field in the IPv4 and IPv6 Routing TLVs (see Sections 7.8.1 and 7.8.2) defined in this document are as follows:
このドキュメントで定義されているIPv4およびIPv6ルーティングTLV（セクション7.8.1および7.8.2を参照）のRoute-Typeフィールドの値は次のとおりです。
+---------+---------------------------------+
| Value | Meaning |
+=========+=================================+
| 0 | User host route |
+---------+---------------------------------+
| 1 | Radius authorization FrameRoute |
+---------+---------------------------------+
| 2 | Network segment route |
+---------+---------------------------------+
| 3 | Gateway route |
+---------+---------------------------------+
| 4 | Radius authorized IP route |
+---------+---------------------------------+
| 5 | L2TP LNS side user route |
+---------+---------------------------------+
| 6-65534 | Unassigned |
+---------+---------------------------------+
| 65535 | Reserved |
+---------+---------------------------------+
Table 14: Route-Type Values
表14：ルートタイプの値
Values of the Access-Type field in the Basic Subscriber TLV (see Section 7.9.1) defined in this document are as follows:
このドキュメントで定義されているBasic Subscriber TLV（セクション7.9.1を参照）のAccess-Typeフィールドの値は次のとおりです。
+--------+---------------------------------------------------------+
| Value | Meaning |
+========+=========================================================+
| 0 | Reserved |
+--------+---------------------------------------------------------+
| 1 | PPP access (PPP [RFC1661]) |
+--------+---------------------------------------------------------+
| 2 | PPP over Ethernet over ATM access (PPPoEoA) |
+--------+---------------------------------------------------------+
| 3 | PPP over ATM access (PPPoA [RFC3336]) |
+--------+---------------------------------------------------------+
| 4 | PPP over Ethernet access (PPPoE [RFC2516]) |
+--------+---------------------------------------------------------+
| 5 | PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) |
+--------+---------------------------------------------------------+
| 6 | PPP over LNS access (PPPoLNS) |
+--------+---------------------------------------------------------+
| 7 | IP over Ethernet DHCP access (IPoE_DHCP) |
+--------+---------------------------------------------------------+
| 8 | IP over Ethernet EAP authentication access (IPoE_EAP) |
+--------+---------------------------------------------------------+
| 9 | IP over Ethernet Layer 3 access (IPoE_L3) |
+--------+---------------------------------------------------------+
| 10 | IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) |
+--------+---------------------------------------------------------+
| 11 | Layer 2 Leased Line access (L2_Leased_Line) |
+--------+---------------------------------------------------------+
| 12 | Layer 2 VPN Leased Line access (L2VPN_Leased_Line) |
+--------+---------------------------------------------------------+
| 13 | Layer 3 Leased Line access (L3_Leased_Line) |
+--------+---------------------------------------------------------+
| 14 | Layer 2 Leased line Sub-User access |
| | (L2_Leased_Line_SUB_USER) |
+--------+---------------------------------------------------------+
| 15 | L2TP LAC tunnel access (L2TP_LAC) |
+--------+---------------------------------------------------------+
| 16 | L2TP LNS tunnel access (L2TP_LNS) |
+--------+---------------------------------------------------------+
| 17-254 | Unassigned |
+--------+---------------------------------------------------------+
| 255 | Reserved |
+--------+---------------------------------------------------------+
Table 15: Access-Type Values
表15：アクセスタイプの値
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The Service, Control, and Management Interfaces between the CP and UP might be across the general Internet or other hostile environment. The ability of an adversary to block or corrupt messages or introduce spurious messages on any one or more of these interfaces would give the adversary the ability to stop subscribers from accessing network services, disrupt existing subscriber sessions, divert traffic, mess up accounting statistics, and generally cause havoc. Damage would not necessarily be limited to one or a few subscribers but could disrupt routing or deny service to one or more instances of the CP or otherwise cause extensive interference. If the adversary knows the details of the UP equipment and its forwarding rule capabilities, the adversary may be able to cause a copy of most or all user data to be sent to an address of the adversary's choosing, thus enabling eavesdropping.
CPとUPの間のサービス、制御、および管理インターフェースは、一般的なインターネットまたは他の敵対的な環境全体に存在する可能性があります。攻撃者がメッセージをブロックまたは破損したり、これらのインターフェイスの1つ以上に偽のメッセージを導入したりすると、攻撃者はサブスクライバによるネットワークサービスへのアクセスを停止し、既存のサブスクライバセッションを中断し、トラフィックを迂回させ、アカウンティング統計を台無しにすることができます。一般的に混乱を引き起こします。損傷は必ずしも1人または数人の加入者に限定されるわけではありませんが、CPの1つ以上のインスタンスへのルーティングを妨害したり、サービスを拒否したり、その他の方法で広範囲の干渉を引き起こす可能性があります。攻撃者がUP機器とその転送ルール機能の詳細を知っている場合、攻撃者はほとんどまたはすべてのユーザーデータのコピーを攻撃者が選択したアドレスに送信して、盗聴を可能にすることができます。
Thus, appropriate protections MUST be implemented to provide integrity, authenticity, and secrecy of traffic over those interfaces. Whether such protection is used is the decision of the network operator. See [RFC6241] for Mi/NETCONF security. Security on the Si is dependent on the tunneling protocol used, which is out of scope for this document. Security for the Ci, over which S-CUSP flows, is further discussed below.
したがって、これらのインターフェースを介したトラフィックの整合性、信頼性、および機密性を提供するために、適切な保護を実装する必要があります。そのような保護が使用されるかどうかは、ネットワークオペレーターの決定です。 Mi / NETCONFセキュリティについては、[RFC6241]を参照してください。 Siのセキュリティは、使用されているトンネリングプロトコルに依存しますが、これはこのドキュメントの範囲外です。 S-CUSPが流れるCiのセキュリティについては、後で詳しく説明します。
S-CUSP messages do not provide security. Thus, if these messages are exchanged in an environment where security is a concern, that security MUST be provided by another protocol such as TLS 1.3 [RFC8446] or IPsec. TLS 1.3 is the mandatory-to-implement protocol for interoperability. The use of a particular security protocol on the Ci is determined by configuration. Such security protocols need not always be used, and lesser security precautions might be appropriate because, in some cases, the communication between the CP and UP is in a benign environment.
S-CUSPメッセージはセキュリティを提供しません。したがって、セキュリティが懸念される環境でこれらのメッセージが交換される場合、そのセキュリティはTLS 1.3 [RFC8446]やIPsecなどの別のプロトコルによって提供される必要があります。 TLS 1.3は、相互運用性を実現するために必須のプロトコルです。 Ciでの特定のセキュリティプロトコルの使用は、構成によって決まります。このようなセキュリティプロトコルは常に使用する必要はなく、場合によっては、CPとUPの間の通信が無害な環境にあるため、セキュリティ対策を少なくすることが適切な場合があります。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, DOI 10.17487/RFC2661, August 1999, <https://www.rfc-editor.org/info/rfc2661>.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター、「レイヤー2トンネリングプロトコル "L2TP"」、RFC 2661、DOI 10.17487 / RFC2661 、1999年8月、<https://www.rfc-editor.org/info/rfc2661>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：/ /www.rfc-editor.org/info/rfc2865>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[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>。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018, <https://doi.org/10.1109/IEEESTD.2018.8403927>.
[802.1Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジおよびブリッジネットワーク」、IEEE 802.1Q-2018、DOI 10.1109 / IEEESTD.2018.8403927、2018年7月、<https://doi.org/10.1109/ IEEESTD.2018.8403927>。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <https://www.rfc-editor.org/info/rfc1661>.
[RFC1661] Simpson、W.、Ed。、 "The Point-to-Point Protocol（PPP）"、STD 51、RFC 1661、DOI 10.17487 / RFC1661、July 1994、<https://www.rfc-editor.org / info / rfc1661>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, <https://www.rfc-editor.org/info/rfc2516>.
[RFC2516] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D。、およびR. Wheeler、 "A Method for Transmitting PPP over Ethernet（PPPoE）"、RFC 2516、DOI 10.17487 / RFC2516、1999年2月、<https://www.rfc-editor.org/info/rfc2516>。
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, <https://www.rfc-editor.org/info/rfc2698>.
[RFC2698] Heinanen、J。およびR. Guerin、「A Two Rate Three Color Marker」、RFC 2698、DOI 10.17487 / RFC2698、1999年9月、<https://www.rfc-editor.org/info/rfc2698>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<https://www.rfc-editor.org/info/ rfc3022>。
[RFC3336] Thompson, B., Koren, T., and B. Buffam, "PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)", RFC 3336, DOI 10.17487/RFC3336, December 2002, <https://www.rfc-editor.org/info/rfc3336>.
[RFC3336] Thompson、B.、Koren、T。、およびB. Buffam、「PPP Over Asynchronous Transfer Mode Adaptation Layer 2（AAL2）」、RFC 3336、DOI 10.17487 / RFC3336、2002年12月、<https：// www。 rfc-editor.org/info/rfc3336>。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511] Farrel、A。、「Routing Backus-Naur Form（RBNF）：A Syntax Rules to Form Encoding Rules in Various Routing Protocol Specifications」、RFC 5511、DOI 10.17487 / RFC5511、2009年4月、<https：// www。 rfc-editor.org/info/rfc5511>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<https：//www.rfc -editor.org/info/rfc7042>。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「Virtual eXtensible Local Area Network（ VXLAN）：A Layer over Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」、RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https://www.rfc-editor.org/info/rfc7348>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[TR-384] Broadband Forum, "Cloud Central Office Reference Architectural Framework", BBF TR-384, January 2018.
[TR-384]ブロードバンドフォーラム、「Cloud Central Office Reference Architectural Framework」、BBF TR-384、2018年1月。
[WT-459] Broadband Forum, "Control and User Plane Separation for a Disaggregated BNG", BBF WT-459, 2019.
[WT-459]ブロードバンドフォーラム、「非集約BNGのコントロールとユーザープレーンの分離」、BBF WT-459、2019。
Acknowledgements
謝辞
The helpful comments and suggestions from the following individuals are hereby acknowledged:
以下の個人からの有益なコメントと提案がここに認められます。
* Loa Andersson
* ロア・アンダーソン
* Greg Mirsky
* グレッグ・ミルスキー
Contributors
貢献者
Zhenqiang Li China Mobile 32 Xuanwumen West Ave Xicheng District Beijing 100053 China
Zは非常に強いl i China Mobile 32 X u Press No Door west av ex I Cheng地区北京100053中国
Email: lizhenqiang@chinamobile.com
Mach(Guoyi) Chen Huawei Technologies Huawei Bldg., No. 156 Beiqing Road Beijing 100095 China
Mach（GU O一）Chen hu Aはテクノロジーhu Aがビルです、No。156 be iblueroad北京100095中国
Email: mach.chen@huawei.com
Zhouyi Yu Huawei Technologies
Zhou-Y uh UAはテクノロジーです
Email: yuzhouyi@huawei.com
Chengguang Niu Huawei Technologies
ChengはGN IU hu Aを技術としてパイプする
Email: chengguang.niu@huawei.com
Zitao Wang Huawei Technologies
Z I Amoy Wang hu Aテクノロジー
Email: wangzitao@huawei.com
Jun Song Huawei Technologies
Jun Song Huawei Technologies
Email: song.jun@huawei.com
Dan Meng H3C Technologies No. 1 Lixing Center No. 8 Guangxun South Street Chaoyang District Beijing 100102 China
ダンメンGH3CテクノロジーNo. 1 lタイプIセンターNo. 8 GUケースGスンサウスストリートC優しい地区北京100102中国
Email: mengdan@h3c.com
Hanlei Liu H3C Technologies No. 1 Lixing Center No. 8 Guangxun South Street Chaoyang District Beijing 100102 China
ハンハンIL IU H3Cテクノロジーno。1 lタイプIセンターno。8 GUケースG Xun南通りCは良い地区北京100102中国
Email: hanlei_liu@h3c.com
Victor Lopez Telefonica Spain
ビクターロペステレフォニカスペイン
Email: victor.lopezalvarez@telefonica.com
Authors' Addresses
著者のアドレス
Shujun Hu China Mobile 32 Xuanwumen West Ave Xicheng District Beijing 100053 China
Shu Junhu China Mobile 32 X u Press No Door west av ex I Cheng District Beijing 100053 China
Email: hushujun@chinamobile.com
Donald Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America
ドナルドイーストレイク3rd Futurewei Technologies 2386 Panoramic Circle Apopka、FL 32703アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Fengwei Qin China Mobile 32 Xuanwumen West Ave Xicheng District Beijing 100053 China
中国での料金はモバイルです32 X u I no Cheng地区北京100053中国
Email: qinfengwei@chinamobile.com
Tee Mong Chua Singapore Telecommunications Limited 31 Exeter Road, #05-04 Comcentre Podium Block SINGAPORE 239732 Singapore
Tee Mong Chua Singapore Telecommunications Limited 31 Exeter Road、＃05-04 Comcentre Podium Block SINGAPORE 239732 Singapore
Email: teemong@singtel.com
Daniel Huang ZTE
ダニエル・ファンZT E
Email: huang.guangping@zte.com.cn