Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6788 A. Kavanagh
Category: Standards Track B. Varga
ISSN: 2070-1721 Ericsson
S. Ooghe
Alcatel-Lucent
E. Nordmark
Cisco
November 2012
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6788 A. Kavanagh
Category: Standards Track B. Varga
ISSN: 2070-1721 Ericsson
S. Ooghe
Alcatel-Lucent
E. Nordmark
Cisco
November 2012
The Line-Identification Option
行标识选项
Abstract
摘要
In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router. This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router.
在基于以太网的聚合网络中，多个用户前提可以逻辑连接到边缘路由器的同一接口。本文档提出了一种边缘路由器使用接收到的路由器请求消息的内容来识别订户处所的方法。适用范围仅限于宽带网络部署场景，其中多个用户端口映射到边缘路由器上的同一虚拟接口。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6788.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6788.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Conventions Used in This Document ..........................6
2. Applicability Statement .........................................6
3. Issues with Identifying the Subscriber Premises in an
N:1 VLAN Model ..................................................7
4. Basic Operation .................................................7
5. AN Behavior .....................................................8
5.1. On Initialization ..........................................8
5.2. On Receiving a Router Solicitation from the End-Device .....8
5.3. On Receiving a Router Advertisement from the Edge Router ...9
5.3.1. Identifying Tunneled Router Advertisements ..........9
5.4. On Detecting a Subscriber Circuit Coming Up ................9
5.5. On Detecting Edge Router Failure ..........................10
5.6. RS Retransmission Algorithm ...............................10
6. Edge Router Behavior ...........................................10
6.1. On Receiving a Tunneled Router Solicitation from the AN ...10
6.2. On Sending a Router Advertisement Towards the End-Device ..10
6.3. Sending Periodic Unsolicited Router Advertisements
Towards the End-Device ....................................11
7. Line-Identification Option (LIO) ...............................12
7.1. Encoding of Line ID .......................................13
8. Garbage Collection of Unused Prefixes ..........................14
9. Interactions with Secure Neighbor Discovery ....................14
10. Acknowledgements ..............................................14
11. Security Considerations .......................................14
12. IANA Considerations ...........................................14
13. References ....................................................15
13.1. Normative References .....................................15
13.2. Informative References ...................................16
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Conventions Used in This Document ..........................6
2. Applicability Statement .........................................6
3. Issues with Identifying the Subscriber Premises in an
N:1 VLAN Model ..................................................7
4. Basic Operation .................................................7
5. AN Behavior .....................................................8
5.1. On Initialization ..........................................8
5.2. On Receiving a Router Solicitation from the End-Device .....8
5.3. On Receiving a Router Advertisement from the Edge Router ...9
5.3.1. Identifying Tunneled Router Advertisements ..........9
5.4. On Detecting a Subscriber Circuit Coming Up ................9
5.5. On Detecting Edge Router Failure ..........................10
5.6. RS Retransmission Algorithm ...............................10
6. Edge Router Behavior ...........................................10
6.1. On Receiving a Tunneled Router Solicitation from the AN ...10
6.2. On Sending a Router Advertisement Towards the End-Device ..10
6.3. Sending Periodic Unsolicited Router Advertisements
Towards the End-Device ....................................11
7. Line-Identification Option (LIO) ...............................12
7.1. Encoding of Line ID .......................................13
8. Garbage Collection of Unused Prefixes ..........................14
9. Interactions with Secure Neighbor Discovery ....................14
10. Acknowledgements ..............................................14
11. Security Considerations .......................................14
12. IANA Considerations ...........................................14
13. References ....................................................15
13.1. Normative References .....................................15
13.2. Informative References ...................................16
Digital Subscriber Line (DSL) is a widely deployed access technology for Broadband Access for Next Generation Networks. While traditional DSL access networks were Point-to-Point Protocol (PPP) [RFC1661] based, some networks are migrating from the traditional PPP access model into a pure IP-based Ethernet aggregated access environment. Architectural and topological models of an Ethernet aggregation network in the context of DSL aggregation are described in [TR101].
数字用户线（DSL）是一种广泛应用于下一代网络宽带接入的接入技术。虽然传统的DSL接入网络基于点对点协议（PPP）[RFC1661]，但一些网络正在从传统的PPP接入模型迁移到纯粹的基于IP的以太网聚合接入环境。[TR101]中描述了DSL聚合环境下以太网聚合网络的架构和拓扑模型。
+----+ +----+ +----------+
|Host|---| RG |----| |
+----+ +----+ | |
| AN |\
+----+ +----+ | | \
|Host|---| RG |----| | \
+----+ +----+ +----------+ \ +----------+
\ | |
+-------------+ | |
| Aggregation | | Edge |
| Network |-------| Router |
+-------------+ | |
/ | |
+----------+ / +----------+
| | /
+----+ +----+ | | /
|Host|---| RG |----| AN |/
+----+ +----+ | |
| |
+----------+
+----+ +----+ +----------+
|Host|---| RG |----| |
+----+ +----+ | |
| AN |\
+----+ +----+ | | \
|Host|---| RG |----| | \
+----+ +----+ +----------+ \ +----------+
\ | |
+-------------+ | |
| Aggregation | | Edge |
| Network |-------| Router |
+-------------+ | |
/ | |
+----------+ / +----------+
| | /
+----+ +----+ | | /
|Host|---| RG |----| AN |/
+----+ +----+ | |
| |
+----------+
Figure 1: Broadband Forum Network Architecture
图1：宽带论坛网络架构
One of the Ethernet and Gigabit-capable Passive Optical Network (GPON) aggregation models specified in this document bridges sessions from multiple user ports behind a DSL Access Node (AN), also referred to as a Digital Subscriber Line Access Multiplexer (DSLAM), into a single VLAN in the aggregation network. This is called the N:1 VLAN allocation model.
本文档中指定的以太网和千兆位无源光网络（GPON）聚合模型之一将会话从DSL接入节点（AN）（也称为数字用户线接入多路复用器（DSLAM））后面的多个用户端口桥接到聚合网络中的单个VLAN中。这称为N:1 VLAN分配模型。
+----------+
| |
| |
| AN |\
| | \
| | \ VLANx
+----------+ \ +----------+
\ | |
+-------------+ | |
| Aggregation | VLANx | Edge |
| Network |-------| Router |
+-------------+ | |
/ | |
+----------+ / +----------+
| | / VLANx
| | /
| AN |/
| |
| |
+----------+
+----------+
| |
| |
| AN |\
| | \
| | \ VLANx
+----------+ \ +----------+
\ | |
+-------------+ | |
| Aggregation | VLANx | Edge |
| Network |-------| Router |
+-------------+ | |
/ | |
+----------+ / +----------+
| | / VLANx
| | /
| AN |/
| |
| |
+----------+
Figure 2: n:1 VLAN model
图2:n:1 VLAN模型
1:1 VLAN A broadband network deployment scenario in which each user port is mapped to a different VLAN on the Edge Router. The uniqueness of the mapping is maintained in the Access Node and across the aggregation network.
1:1 VLAN宽带网络部署方案，其中每个用户端口映射到边缘路由器上的不同VLAN。映射的唯一性在访问节点和整个聚合网络中保持。
N:1 VLAN A broadband network deployment scenario in which multiple user ports are mapped to the same VLAN on the Edge Router. The user ports may be located in the same or different Access Nodes.
N:1 VLAN一种宽带网络部署方案，其中多个用户端口映射到边缘路由器上的同一VLAN。用户端口可以位于相同或不同的接入节点中。
GPON Gigabit-capable Passive Optical Network is an optical access network that has been introduced into the Broadband Forum architecture in [TR156].
GPON千兆位无源光网络是一种光接入网络，已在[TR156]中引入宽带论坛架构。
AN A DSL or a GPON Access Node. The Access Node terminates the physical layer (e.g., DSL termination function or GPON termination function), may physically aggregate other nodes implementing such functionality, or may perform both functions at the same time. This node contains at least one standard Ethernet interface that serves as its "northbound" interface into which it aggregates traffic from several user ports or Ethernet-based "southbound" interfaces. It does not implement an IPv6 stack but performs some limited inspection/modification of IPv6 packets. The IPv6 functions required on the Access Node are described in Section 5 of [TR177].
DSL或GPON接入节点。接入节点终止物理层（例如，DSL终止功能或GPON终止功能），可以物理地聚合实现这种功能的其他节点，或者可以同时执行这两种功能。此节点包含至少一个标准以太网接口，该接口用作其“北向”接口，它将来自多个用户端口或基于以太网的“南向”接口的流量聚合到该接口中。它不实现IPv6堆栈，但对IPv6数据包执行一些有限的检查/修改。[TR177]第5节描述了接入节点上所需的IPv6功能。
Aggregation Network The part of the network stretching from the Access Nodes to the Edge Router. In the context of this document, the aggregation network is considered to be Ethernet based, providing standard Ethernet interfaces at the edges, for connecting the Access Nodes and the broadband network. It is comprised of Ethernet switches that provide very limited IP functionality (e.g., IGMP snooping, Multicast Listener Discovery (MLD) snooping, etc.).
聚合网络从接入节点延伸到边缘路由器的网络部分。在本文件的上下文中，聚合网络被认为是基于以太网的，在边缘提供标准以太网接口，用于连接接入节点和宽带网络。它由提供非常有限的IP功能（例如，IGMP侦听、多播侦听器发现（MLD）侦听等）的以太网交换机组成。
RG A residential gateway device. It can be a Layer-3 (routed) device or a Layer-2 (bridged) device. The residential gateway for Broadband Forum networks is defined in [TR124].
RG是一种住宅网关设备。它可以是第3层（路由）设备或第2层（桥接）设备。宽带论坛网络的住宅网关定义见[TR124]。
Edge Router The Edge Router, also known as the Broadband Network Gateway (BNG), is the first IPv6 hop for the user. In cases where the RG is bridged, the BNG acts as the default router for the hosts behind the RG. In cases where the RG is routed, the BNG acts as the default router for the RG itself. This node implements IPv6 router functionality.
边缘路由器边缘路由器，也称为宽带网络网关（BNG），是用户的第一个IPv6跃点。在RG桥接的情况下，BNG充当RG后面主机的默认路由器。在路由RG的情况下，BNG充当RG本身的默认路由器。此节点实现IPv6路由器功能。
Host A node that implements IPv6 host functionality.
主机实现IPv6主机功能的节点。
End-Device A node that sends Router Solicitations and processes received Router Advertisements. When a Layer-3 (L3) RG is used, it is considered an end-device in the context of this document. When a Layer-2 (L2) RG is used, the host behind the RG is considered to be an end-device in the context of this document.
终端设备发送路由器请求并处理接收到的路由器播发的节点。当使用第3层（L3）RG时，在本文件的上下文中，它被视为终端设备。使用第2层（L2）RG时，RG后面的主机在本文档上下文中被视为终端设备。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The Line-Identification Option (LIO) is intended to be used only for the N:1 VLAN deployment model. For the other VLAN deployment models, line identification can be achieved differently. The mechanism described in this document allows the connection of hosts that only support IPv6 stateless address auto-configuration to attach to networks that use the N:1 VLAN deployment model.
线路标识选项（LIO）仅用于N:1 VLAN部署模型。对于其他VLAN部署模型，可以以不同的方式实现线路标识。本文档中描述的机制允许仅支持IPv6无状态地址自动配置的主机连接到使用N:1 VLAN部署模型的网络。
When the Dynamic Host Configuration Protocol (DHCP) [RFC3315] is used for IPv6 address assignment, it has the side-effect of providing end-device-initiated reliability as well as inactivity detection. The reliability is provided by the end-device continuing to retransmit DHCP messages until it receives a response), and inactivity is detected by the end-device not renewing its DHCP lease. The "IPv6 Stateless Address Autoconfiguration" protocol [RFC4862] was not designed to satisfy such requirements [RSDA]. While this option improves the reliability of operation in deployments that use Router Solicitations rather than DHCP, there are some limitations as specified below.
当动态主机配置协议（DHCP）[RFC3315]用于IPv6地址分配时，它具有提供终端设备启动的可靠性以及不活动检测的副作用。可靠性由终端设备提供，终端设备继续重新传输DHCP消息，直到接收到响应为止），并且未续订其DHCP租约的终端设备检测到不活动。“IPv6无状态地址自动配置”协议[RFC4862]的设计不符合此类要求[RSDA]。虽然此选项提高了使用路由器请求而不是DHCP的部署中操作的可靠性，但仍有一些限制，如下所述。
The mechanism described in this document deals with the loss of subscriber-originated Router Solicitations (RSes) by initiating RSes at the AN, which improves robustness over solely relying on the end-device's few initial retransmissions of RSes.
本文档中描述的机制通过在AN处发起rse来处理来自订户的路由器请求（rse）的丢失，这与仅依赖终端设备的少量初始rse重传相比提高了鲁棒性。
However, the AN retransmissions imply that some information (e.g., the subscriber's MAC address) that was obtained by the Edge Router from subscriber-originated RSes may no longer be available. For example, since there is no L2 frame received from the subscriber in case of an RS sent by an AN, the L2-address information of the end-device cannot be determined. One piece of L2-address information currently used in some broadband networks is the MAC address. For
然而，AN重传意味着边缘路由器从用户发起的rse获得的某些信息（例如，用户的MAC地址）可能不再可用。例如，由于在an发送RS的情况下没有从订户接收到L2帧，因此无法确定终端设备的L2地址信息。目前在一些宽带网络中使用的一条L2地址信息是MAC地址。对于
this reason, the solution described in this document is NOT RECOMMENDED for networks that require the MAC address of the endpoint for identification.
因此，对于需要端点MAC地址进行标识的网络，不建议使用本文档中描述的解决方案。
There is no indication when a subscriber is no longer active. Thus, this protocol cannot be used to automatically reclaim resources, such as prefixes, that are associated with an active subscriber. See Section 8. Thus, this protocol is NOT RECOMMENDED for networks that require automatic notification when a subscriber is no longer active.
订阅者不再活动时没有指示。因此，此协议不能用于自动回收与活动订阅服务器关联的资源，例如前缀。见第8节。因此，当订户不再处于活动状态时，不建议将此协议用于需要自动通知的网络。
This mechanism by itself provides no protection against the loss of RS-induced state in access routers that would lead to loss of IPv6 connectivity for end-devices. Given that regular IPv6 hosts do not have RS retransmission behavior that would allow automatic recovery from such a failure, this mechanism SHOULD only be used in deployments employing N:1 VLANs.
这种机制本身无法防止访问路由器中RS诱导状态的丢失，这将导致终端设备的IPv6连接丢失。鉴于常规IPv6主机不具有允许从此类故障中自动恢复的RS重传行为，此机制应仅在使用N:1 VLAN的部署中使用。
In a DSL- or GPON-based fixed broadband network, IPv6 end-devices are connected to an AN. Today, these end-devices will typically send a Router Solicitation message to the Edge Router, to which the Edge Router responds with a Router Advertisement message. The Router Advertisement typically contains a prefix that the end-devices will use to automatically configure an IPv6 address. Upon sending the Router Solicitation message, the node connecting the end-device on the access circuit, typically an AN, forwards the RS to the Edge Router upstream over a switched network. In such Ethernet-based aggregation networks, several subscriber premises may be connected to the same interface of an Edge Router (e.g., on the same VLAN). However, the Edge Router requires some information to identify the end-device on the circuit. To accomplish this, the AN needs to add line-identification information to the Router Solicitation message and forward this to the Edge Router. This is analogous to the case where DHCP is being used, and the line-identification information is inserted by a DHCP relay agent [RFC3315]. This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages. Note that there might be several end-devices located on the same subscriber premises.
在基于DSL或GPON的固定宽带网络中，IPv6终端设备连接到an。今天，这些终端设备通常将向边缘路由器发送路由器请求消息，边缘路由器用路由器广告消息对其作出响应。路由器公告通常包含一个前缀，终端设备将使用该前缀自动配置IPv6地址。在发送路由器请求消息时，连接接入电路上的终端设备（通常是an）的节点通过交换网络将RS转发到上游边缘路由器。在这种基于以太网的聚合网络中，多个订户场所可以连接到边缘路由器的同一接口（例如，在同一VLAN上）。然而，边缘路由器需要一些信息来识别电路上的终端设备。为此，AN需要将线路标识信息添加到路由器请求消息中，并将其转发到边缘路由器。这类似于使用DHCP的情况，线路标识信息由DHCP中继代理插入[RFC3315]。本文档提出了一种边缘路由器使用接收到的路由器请求消息的内容来识别订户处所的方法。请注意，可能有多个终端设备位于同一个订户场所。
This document uses a mechanism that tunnels Neighbor Discovery (ND) packets inside another IPv6 packet that uses a destination option (Line-ID option) to convey line-identification information as depicted in Figure 3. The use of the Line-ID option in any other IPv6 datagrams, including untunneled RS and RA messages, is not
本文档使用一种机制，将邻居发现（ND）数据包隧道到另一个IPv6数据包中，该数据包使用目的地选项（线路ID选项）来传输线路标识信息，如图3所示。不允许在任何其他IPv6数据报中使用Line ID选项，包括未启用的RS和RA消息
defined by this document. The ND packets are left unmodified inside the encapsulating IPv6 packet. In particular, the Hop Limit field of the ND message is not decremented when the packet is being tunneled. This is because an ND message whose Hop Limit is not 255 will be discarded by the receiver of such messages, as described in Sections 6.1.1 and 6.1.2 of [RFC4861].
由本文件定义。ND数据包在封装的IPv6数据包内保持不变。具体地，当分组被隧道化时，ND消息的跳数限制字段不减小。这是因为跳转限制不是255的ND消息将被此类消息的接收器丢弃，如[RFC4861]第6.1.1和6.1.2节所述。
+----+ +----+ +-----------+
|Host| | AN | |Edge Router|
+----+ +----+ +-----------+
| RS | |
|---------->| |
| | |
| |Tunneled RS(LIO)|
| |--------------->|
| | |
| |Tunneled RA(LIO)|
| |<---------------|
| RA | |
|<----------| |
| | |
+----+ +----+ +-----------+
|Host| | AN | |Edge Router|
+----+ +----+ +-----------+
| RS | |
|---------->| |
| | |
| |Tunneled RS(LIO)|
| |--------------->|
| | |
| |Tunneled RA(LIO)|
| |<---------------|
| RA | |
|<----------| |
| | |
Figure 3: Basic Message Flow
图3：基本消息流
On initialization, the AN MUST join the All-BBF-Access-Nodes multicast group on all its upstream interfaces towards the Edge Router.
在初始化时，AN必须在其所有上游接口上向边缘路由器加入所有BBF访问节点多播组。
When an end-device sends out a Router Solicitation, it is received by the AN. The AN identifies these messages by looking for ICMPv6 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. The AN intercepts and then tunnels the received Router Solicitation in a newly created IPv6 datagram with the Line-Identification Option (LIO). The AN forms a new IPv6 datagram whose payload is the received Router Solicitation message as described in [RFC2473], except that the Hop Limit field of the Router Solicitation message MUST NOT be decremented. If the AN has an IPv6 address, it MUST use this address in the Source Address field of the outer IPv6 datagram. Otherwise, the AN MUST copy the source address from the received Router Solicitation into the Source Address field of the outer IPv6 datagram. The destination address of the outer IPv6 datagram MUST be
当终端设备发送路由器请求时，an接收该请求。AN通过查找ICMPv6类型为133的ICMPv6消息（IPv6下一个标头值为58）来识别这些消息。AN使用线路标识选项（LIO）在新创建的IPv6数据报中拦截并隧道接收到的路由器请求。AN形成一个新的IPv6数据报，其有效负载是[RFC2473]中所述的接收到的路由器请求消息，但路由器请求消息的跃点限制字段不得减少。如果AN具有IPv6地址，则必须在外部IPv6数据报的源地址字段中使用此地址。否则，AN必须将收到的路由器请求中的源地址复制到外部IPv6数据报的源地址字段中。外部IPv6数据报的目标地址必须为
copied from the destination address of the tunneled RS. The AN MUST include a destination options header between the outer IPv6 header and the payload. It MUST insert an LIO destination option and set the Line ID field of the option to contain the circuit identifier corresponding to the logical access loop port of the AN from which the RS was initiated.
从隧道RS的目标地址复制。AN必须在外部IPv6标头和有效负载之间包含目标选项标头。它必须插入一个LIO目的地选项，并将该选项的Line ID字段设置为包含与从中启动RS的an的逻辑访问环路端口相对应的电路标识符。
When the Edge Router sends out a tunneled Router Advertisement in response to the RS, it is received by the AN. If there is an LIO present, the AN MUST use the line-identification data of the LIO to identify the subscriber agent circuit of the AN on which the RA should be sent. The AN MUST then remove the outer IPv6 header of this tunneled RA and multicast the inner packet (the original RA) on this specific subscriber circuit.
当边缘路由器响应于RS发送隧道路由器广告时，AN接收该广告。如果存在LIO，an必须使用LIO的线路标识数据来标识an的用户代理电路，RA应在其上发送。然后，AN必须删除此隧道RA的外部IPv6报头，并在该特定订户电路上多播内部数据包（原始RA）。
The AN can identify tunneled RAs by installing filters based on the destination address (All-BBF-Access-Nodes, which is a reserved link-local scoped multicast address) of the outer packets and the presence of a destination option header with an LIO destination option.
AN可以通过安装基于外部分组的目的地地址（所有BBF接入节点，它是保留链路本地作用域多播地址）和具有LIO目的地选项的目的地选项报头的存在的过滤器来识别隧道RAs。
RSes initiated by end-devices as described in Section 5.2 may be lost due to lack of connectivity between the AN and the end-device. To ensure that the end-device will receive an RA, the AN needs to trigger the sending of periodic RAs on the Edge Router. For this purpose, the AN needs to inform the Edge Router that a subscriber circuit has come up. Each time the AN detects that a subscriber circuit has come up, it MUST create a Router Solicitation message as described in Section 6.3.7 of [RFC4861]. It MUST use the unspecified address as the source address of this RS. It MUST then tunnel this RS towards the Edge Router as described in Section 5.2.
如第5.2节所述，由终端设备启动的RSE可能会由于AN和终端设备之间缺乏连接而丢失。为了确保终端设备将接收到RA，an需要在边缘路由器上触发定期RAs的发送。为此，AN需要通知边缘路由器用户电路已经出现。每次AN检测到用户电路出现时，必须按照[RFC4861]第6.3.7节中的说明创建路由器请求消息。它必须使用未指定的地址作为该RS的源地址。然后，它必须按照第5.2节所述将该RS隧道到边缘路由器。
In case there are connectivity issues between the AN and the Edge Router, the RSes initiated by the AN can be lost. The AN SHOULD continue retransmitting the Router Solicitations following the algorithm described in Section 5.6 for a given LIO until it receives an RA for that specific LIO.
如果AN和边缘路由器之间存在连接问题，则AN发起的RSE可能会丢失。AN应按照第5.6节中描述的算法，继续为给定LIO重新传输路由器请求，直到收到该特定LIO的RA。
When the Edge Router reboots and loses state or is replaced by a new Edge Router, the AN will detect it using connectivity check mechanisms that are already in place in broadband networks (e.g., Bidirectional Forwarding Detection). When such Edge Router failure is detected, the AN needs to start transmitting RSes for each of its subscriber circuits that have come up, as described in Section 5.4.
当边缘路由器重新启动并失去状态或被新的边缘路由器替换时，AN将使用宽带网络中已有的连接检查机制（例如，双向转发检测）对其进行检测。当检测到这种边缘路由器故障时，AN需要开始为其出现的每个用户电路发送RSE，如第5.4节所述。
The AN SHOULD use the exponential backoff algorithm for retransmits that is described in Section 14 of [RFC3315] in order to continuously retransmit the Router Solicitations for a given LIO until a response is received for that specific LIO. The AN SHOULD use the following variables as input to the retransmission algorithm:
AN应使用[RFC3315]第14节中描述的用于重传的指数退避算法，以便连续重传给定LIO的路由器请求，直到接收到该特定LIO的响应。AN应使用以下变量作为重传算法的输入：
Initial retransmission time (IRT) 1 Second Maximum retransmission time (MRT) 30 Seconds Maximum retransmission count (MRC) 0 Maximum retransmission duration (MRD) 0
初始重传时间（IRT）1秒最大重传时间（MRT）30秒最大重传计数（MRC）0最大重传持续时间（MRD）0
When the Edge Router receives a tunneled Router Solicitation forwarded by the AN, it needs to check if there is an LIO destination option present in the outer datagram. The Edge Router can use the contents of the Line ID field to lookup the addressing information and policy that need to be applied to the line from which the Router Solicitation was received. The Edge Router MUST then process the inner RS message as specified in [RFC4861].
当边缘路由器接收到AN转发的隧道路由器请求时，它需要检查外部数据报中是否存在LIO目的地选项。边缘路由器可以使用Line ID字段的内容来查找需要应用于接收路由器请求的线路的寻址信息和策略。然后，边缘路由器必须按照[RFC4861]中的规定处理内部RS消息。
When the Edge Router sends out a Router Advertisement in response to a tunneled RS that included an LIO, it MUST tunnel the Router Advertisement in a newly created IPv6 datagram with the LIO as described below. First, the Edge Router creates the Router Advertisement message as described in Section 6.2.3 of [RFC4861]. The Edge Router MUST include a Prefix Information option in this RA that contains the prefix that corresponds to the received LIO. (The LIO from the received tunneled RS is usually passed on from the Edge Router to some form of provisioning system that returns the prefix to be included in the RA. It could e,g., be based on RADIUS.) Then, the Edge Router forms the new IPv6 datagram whose payload is the Router Advertisement message, as described in [RFC2473], except that
当边缘路由器发送路由器广告以响应包括LIO的隧道RS时，它必须使用LIO在新创建的IPv6数据报中隧道路由器广告，如下所述。首先，边缘路由器按照[RFC4861]第6.2.3节所述创建路由器公告消息。边缘路由器必须在此RA中包含前缀信息选项，该选项包含与接收到的LIO相对应的前缀。（来自接收到的隧道RS的LIO通常从边缘路由器传递到某种形式的供应系统，该系统返回要包含在RA中的前缀。例如，它可以基于RADIUS。）然后，边缘路由器形成新的IPv6数据报，其有效负载是路由器广告消息，如[RFC2473]所述，除了
the Hop Limit field of the Router Advertisement message MUST NOT be decremented. The Edge router MUST use a link-local IPv6 address on the outgoing interface in the Source Address field of the outer IPv6 datagram. The Edge Router MUST include a destination options header between the outer IPv6 header and the payload. It MUST insert an LIO and set the Line ID field of the option to contain the same value as that of the Line-ID option in the received RS. The IPv6 destination address of the inner RA MUST be set to the all-nodes multicast address.
路由器广告消息的跃点限制字段不得递减。边缘路由器必须在外部IPv6数据报的源地址字段中的传出接口上使用链路本地IPv6地址。边缘路由器必须在外部IPv6标头和有效负载之间包含目标选项标头。它必须插入一个LIO，并将选项的Line ID字段设置为包含与接收到的RS中Line ID选项相同的值。内部RA的IPv6目标地址必须设置为所有节点多播地址。
If the Source Address field of the received IPv6 datagram was not the unspecified address, the Edge Router MUST copy this address into the Destination Address field of the outer IPv6 datagram sent back towards the AN. The link-layer destination address of the outer IPv6 datagram containing the outer IPv6 datagram MUST be resolved using regular Neighbor Discovery procedures.
如果接收到的IPv6数据报的源地址字段不是未指定的地址，则边缘路由器必须将该地址复制到发送回AN的外部IPv6数据报的目标地址字段中。必须使用常规邻居发现过程解析包含外部IPv6数据报的外部IPv6数据报的链路层目标地址。
If the Source Address field of the received IPv6 datagram was the unspecified address, the destination address of the outer IPv6 datagram MUST be set to the well-known link-local scope All-BBF-Access-Nodes multicast address (ff02::10). The link-layer destination address of the tunneled RA MUST be set to the unicast link-layer address of the AN that sent the tunneled Router Solicitation that is being responded to.
如果接收到的IPv6数据报的源地址字段是未指定的地址，则外部IPv6数据报的目标地址必须设置为众所周知的链路本地作用域所有BBF访问节点多播地址（ff02:：10）。隧道RA的链路层目标地址必须设置为发送正在响应的隧道路由器请求的AN的单播链路层地址。
The Edge Router MUST ensure that it does not transmit tunneled RAs whose size is larger than the MTU of the link between the Edge Router and the AN, which would require that the outer IPv6 datagram undergo fragmentation. This limitation is imposed because the AN may not be capable of handling the reassembly of such fragmented datagrams.
边缘路由器必须确保其不会传输大小大于边缘路由器和AN之间链路MTU的隧道RAs，这将要求外部IPv6数据报经历碎片化。施加此限制是因为AN可能无法处理此类碎片数据报的重新组装。
6.3. Sending Periodic Unsolicited Router Advertisements Towards the End-Device
6.3. 向终端设备定期发送未经请求的路由器广告
After sending a tunneled Router Advertisement as specified in Section 6.2 in response to a received RS, the Edge Router MUST store the mapping between the LIO and the prefixes contained in the Router Advertisement. It should then initiate periodic sending of unsolicited Router Advertisements as described in Section 6.2.3. of [RFC4861] . The Router Advertisements MUST be created and tunneled as described in Section 6.2. The Edge Router MAY stop sending Router Advertisements if it receives a notification from the AN that the subscriber circuit has gone down. This notification can be received out-of-band using a mechanism such as the Access Node Control Protocol (ANCP). Please consult Section 8 for more details.
在发送第6.2节中规定的隧道路由器公告以响应接收到的RS后，边缘路由器必须存储LIO和路由器公告中包含的前缀之间的映射。然后，它应按照第6.2.3节所述，定期发送未经请求的路由器广告。属于[RFC4861]。路由器广告必须按照第6.2节所述进行创建和隧道传输。如果边缘路由器接收到来自AN的订户电路发生故障的通知，则可以停止发送路由器广告。可以使用诸如接入节点控制协议（ANCP）之类的机制在带外接收该通知。有关更多详细信息，请参阅第8节。
The Line-Identification Option (LIO) is a destination option that can be included in IPv6 datagrams that tunnel Router Solicitation and Router Advertisement messages. The use of the Line-ID option in any other IPv6 datagrams is not defined by this document. Multiple Line-ID destination options MUST NOT be present in the same IPv6 datagram. The LIO has no alignment requirement.
线路标识选项（LIO）是一个目标选项，可包含在IPv6数据报中，用于传输路由器请求和路由器广告消息。本文档未定义在任何其他IPv6数据报中使用Line ID选项。同一IPv6数据报中不得存在多个线路ID目标选项。LIO没有校准要求。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LineIDLen | Line ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LineIDLen | Line ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Line-Identification Option Layout
图4：线路标识选项布局
Option Type
选项类型
8-bit identifier of the type of option. The option identifier for the Line-Identification Option (0x8C) has been allocated by the IANA.
选项类型的8位标识符。线路标识选项（0x8C）的选项标识符已由IANA分配。
Option Length
选项长度
8-bit unsigned integer. The length of the option (excluding the Option Type and Option Length fields). The value MUST be greater than 0.
8位无符号整数。选项的长度（不包括选项类型和选项长度字段）。该值必须大于0。
LineIDLen
莱尼德伦
8-bit unsigned integer. The length of the Line ID field in number of octets.
8位无符号整数。行ID字段的长度，以八位字节为单位。
Line ID
线路ID
Variable-length data inserted by the AN describing the subscriber-agent circuit identifier corresponding to the logical access loop port of the AN from which the RS was initiated. The line identification MUST be unique across all the ANs that share a link to the Edge Router, e.g., one such line- identification scheme is described in Section 3.9 of [TR101]. The line identification should be encoded as specified in Section 7.1.
由AN插入的可变长度数据，描述与从中启动RS的AN的逻辑访问环路端口相对应的订户代理电路标识符。线路标识必须在共享到边缘路由器的链路的所有AN中是唯一的，例如，[TR101]第3.9节中描述了一个这样的线路标识方案。线路标识应按照第7.1节的规定进行编码。
This IPv6 Destination option is derived from an existing widely deployed DHCPv6 option [RFC4649], which is in turn derived from a widely deployed DHCPv4 option [RFC3046]. These options derive from and cite the basic DHCP options specification [RFC2132]. These widely deployed DHCP options use the Network Virtual Terminal (NVT) character set [RFC2132] [RFC0020]. Since the data carried in the Line-ID option is used in the same manner by the provisioning systems as the DHCP options, it is beneficial for it to maintain the same encoding as the DHCP options.
此IPv6目标选项派生自现有广泛部署的DHCPv6选项[RFC4649]，该选项又派生自广泛部署的DHCPv4选项[RFC3046]。这些选项源自并引用基本DHCP选项规范[RFC2132]。这些广泛部署的DHCP选项使用网络虚拟终端（NVT）字符集[RFC2132][RFC0020]。由于线路ID选项中携带的数据在供应系统中的使用方式与DHCP选项相同，因此保持与DHCP选项相同的编码是有益的。
The IPv6 Line ID option contains a description that identifies the line using only character positions (decimal 32 to decimal 126, inclusive) of the US-ASCII character set [X3.4] [RFC0020]. Consistent with [RFC2132], [RFC3046], and [RFC4649], the Line ID field SHOULD NOT contain the US-ASCII NUL character (decimal 0). However, implementations receiving this option MUST NOT fail merely because an ASCII NUL character is (erroneously) present in the Line ID field.
IPv6 Line ID选项包含一个描述，该描述仅使用US-ASCII字符集[X3.4][RFC0020]的字符位置（十进制32到十进制126，含）来标识该行。与[RFC2132]、[RFC3046]和[RFC4649]一致，行ID字段不应包含US-ASCII NUL字符（十进制0）。但是，接收此选项的实现不能仅仅因为行ID字段中（错误地）存在ASCII NUL字符而失败。
Some existing widely deployed implementations of Edge Routers and ANs that support the previously mentioned DHCP option only support US-ASCII and strip the high-order bit from any 8-bit characters entered by the device operator. The previously mentioned DHCP options do not support 8-bit character sets either. Therefore, for compatibility with the installed base and to maximize interoperability, the high-order bit of each octet in this field MUST be set to zero by any device inserting this option in an IPv6 packet.
支持前面提到的DHCP选项的边缘路由器和AN的一些现有广泛部署的实现仅支持US-ASCII，并从设备操作员输入的任何8位字符中去除高阶位。前面提到的DHCP选项也不支持8位字符集。因此，为了与安装基础兼容并最大限度地提高互操作性，任何在IPv6数据包中插入此选项的设备都必须将此字段中每个八位字节的高位设置为零。
Consistent with [RFC3046] and [RFC4649], this option always uses binary comparison. Therefore, two Line IDs MUST be equal when they match when compared byte-by-byte. Line-ID A and Line-ID B match byte-by-byte when (1) A and B have the same number of bytes, and (2) for all byte indexes P in A: the value of A at index P has the same binary value as the value of B at index P.
与[RFC3046]和[RFC4649]一致，此选项始终使用二进制比较。因此，当逐字节比较时，两个行ID在匹配时必须相等。当（1）A和B具有相同的字节数时，行ID A和行ID B逐字节匹配，（2）对于A中的所有字节索引P：索引P处A的值与索引P处B的值具有相同的二进制值。
Two Line IDs MUST NOT be equal if they do not match byte-by-byte. For example, an IPv6 Line-ID option containing "f123" is not equal to a Line-ID option "F123".
如果两行ID逐字节不匹配，则它们不能相等。例如，包含“f123”的IPv6线路ID选项不等于线路ID选项“f123”。
Intermediate systems MUST NOT alter the contents of the Line ID.
中间系统不得更改行ID的内容。
Following the mechanism described in this document, the broadband network associates a prefix to a subscriber line based on the LIO. Even when the subscriber line goes down temporarily, this prefix stays allocated to that specific subscriber line, i.e., the prefix is not returned to the unused pool. When a subscriber line no longer needs a prefix, the prefix can be reclaimed by manual action dissociating the prefix from the LIO in the backend systems.
按照本文中描述的机制，宽带网络基于LIO将前缀与订户线路相关联。即使当用户线路暂时关闭时，该前缀仍被分配给该特定的用户线路，即前缀不会返回到未使用的池。当用户线路不再需要前缀时，可以通过手动操作将前缀与后端系统中的LIO分离来回收前缀。
Since the RS/RA packets that are protected by the "SEcure Neighbor Discovery (SEND)" [RFC3971] are not modified in any way by the mechanism described in this document, there are no issues with SEND verification.
由于受“安全邻居发现（发送）”[RFC3971]保护的RS/RA数据包未通过本文档中描述的机制进行任何修改，因此发送验证不存在任何问题。
The authors would like to thank Margaret Wasserman, Mark Townsley, David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson, Glen Turner, Kathleen Moriarty, David Sinicrope, Dan Harkins, Stephen Farrell, Barry Leiba, Sean Turner, Ralph Droms, and Mohammed Boucadair for reviewing this document and suggesting changes.
作者要感谢玛格丽特·瓦瑟曼、马克·汤斯利、大卫·迈尔斯、约翰·凯帕利马利尔、埃里克·利维·阿贝格诺利、托马斯·纳滕、奥拉夫·邦内斯、托马斯·哈格、沃伊切赫·德克、布莱恩·哈伯曼、奥勒·特隆、赫曼特·辛格、贾里·阿克科、乔尔·哈尔彭、鲍勃·欣登、阿特金森、格伦·特纳、凯瑟琳·莫里亚蒂、大卫·西尼克罗普、丹·哈金斯、斯蒂芬·法雷尔、，Barry Leiba、Sean Turner、Ralph Droms和Mohammed Boucadair对本文件进行了审查并提出了修改建议。
The line identification information inserted by the AN or the Edge Router is not protected. This means that this option may be modified, inserted, or deleted without being detected. In order to ensure validity of the contents of the Line ID field, the network between the AN and the Edge Router needs to be trusted.
由AN或边缘路由器插入的线路标识信息不受保护。这意味着可以在不被检测的情况下修改、插入或删除此选项。为了确保Line ID字段内容的有效性，需要信任AN和边缘路由器之间的网络。
This document defines a new IPv6 destination option for carrying line identification. IANA has assigned the following new destination option type in the "Destination Options and Hop-by-Hop Options" registry maintained at <http://www.iana.org/assignments/ipv6-parameters>:
本文档定义了用于承载线路标识的新IPv6目标选项。IANA已在维护于的“目的地选项和逐跳选项”注册表中分配了以下新的目的地选项类型<http://www.iana.org/assignments/ipv6-parameters>:
0x8C Line-Identification Option [RFC6788]
0x8C线路标识选项[RFC6788]
The act bits for this option are 10 and the chg bit is 0.
此选项的act位为10，chg位为0。
Per this document, IANA has also allocated the following well-known link-local scope multicast address from the "IPv6 Multicast Address Space Registry" located at <http://www.iana.org/assignments/ipv6-multicast-addresses/>:
根据本文件，IANA还从位于的“IPv6多播地址空间注册表”中分配了以下众所周知的链路本地作用域多播地址：<http://www.iana.org/assignments/ipv6-multicast-addresses/>:
FF02:0:0:0:0:0:0:10 All-BBF-Access-Nodes [RFC6788]
FF02:0:0:0:0:0:0:10 All-BBF-Access-Nodes [RFC6788]
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[TR101] Broadband Forum, "Migration to Ethernet-based DSL aggregation", <http://www.broadband-forum.org/ technical/download/TR-101.pdf>.
[TR101]宽带论坛，“迁移到基于以太网的DSL聚合”<http://www.broadband-forum.org/ 技术/下载/TR-101.pdf>。
[TR124] Broadband Forum, "Functional Requirements for Broadband Residential Gateway Devices", <http://www.broadband-forum.org/technical/ download/TR-124_Issue-2.pdf>.
[TR124]宽带论坛，“宽带住宅网关设备的功能要求”<http://www.broadband-forum.org/technical/ 下载/TR-124_Issue-2.pdf>。
[TR156] Broadband Forum, "Using GPON Access in the context of TR-101", <http://www.broadband-forum.org/ technical/download/TR-156.pdf>.
[TR156]宽带论坛，“在TR-101环境下使用GPON接入”<http://www.broadband-forum.org/ 技术/下载/TR-156.pdf>。
[TR177] Broadband Forum, "IPv6 in the context of TR-101", <www.broadband-forum.org/technical/download/TR-177.pdf>.
[TR177]宽带论坛，“TR-101背景下的IPv6”，<www.Broadband-Forum.org/technical/download/TR-177.pdf>。
[X3.4] American National Standards Institute, "American Standard Code for Information Interchange (ASCII)", Standard X3.4, 1968.
[X3.4]美国国家标准协会，“美国信息交换标准代码（ASCII）”，标准X3.41968。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020]Cerf，V.，“网络交换的ASCII格式”，RFC 20，1969年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649]Volz，B.，“IPv6（DHCPv6）中继代理远程ID选项的动态主机配置协议”，RFC 4649，2006年8月。
[RSDA] Dec, W., "IPv6 Router Solicitation Driven Access Considered Harmful", Work in Progress, June 2011.
[RSDA]Dec，W.，“被认为有害的IPv6路由器请求驱动访问”，正在进行的工作，2011年6月。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson加拿大魁北克皇家山Decarie镇8400大道
EMail: suresh.krishnan@ericsson.com
EMail: suresh.krishnan@ericsson.com
Alan Kavanagh Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
艾伦·卡瓦纳·爱立信加拿大魁北克皇家山德卡里镇8400大道
EMail: alan.kavanagh@ericsson.com
EMail: alan.kavanagh@ericsson.com
Balazs Varga Ericsson Konyves Kalman krt. 11. B. 1097 Budapest Hungary
巴拉兹·瓦尔加·爱立信·科尼维斯·卡尔曼·克尔特。11B.1097匈牙利布达佩斯
EMail: balazs.a.varga@ericsson.com
EMail: balazs.a.varga@ericsson.com
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 2018比利时安特卫普
Phone: EMail: sven.ooghe@alcatel-lucent.com
电话：电子邮件：斯文。ooghe@alcatel-朗讯网
Erik Nordmark Cisco 510 McCarthy Blvd. Milpitas, CA, 95035 USA
埃里克诺德马克思科510麦卡锡大道。加利福尼亚州米尔皮塔斯，美国95035
Phone: +1 408 527 6625
EMail: nordmark@cisco.com
Phone: +1 408 527 6625
EMail: nordmark@cisco.com