3 Mar 2003 16:20
3 Mar 2003 16:10
draft-ietf-l2tpext-mcast-03.txt
BOURDON Gilles FTRD/DAC/ISS <gilles.bourdon <at> rd.francetelecom.com>
2003-03-03 15:10:07 GMT
2003-03-03 15:10:07 GMT
For your information, the last version of draft-ietf-l2tpext-mcast-03.txt
I missed the internet-draft submission cut-off for one hour... Anyway, comments are welcome !
Gilles.
<<draft-ietf-l2tpext-mcast-03.txt>>
Network Working Group G. Bourdon
Internet Draft France Telecom R&D
Document: draft-ietf-l2tpext-mcast-03.txt March 2003
Category: Experimental
L2TP Multicast Extension
<draft-ietf-l2tpext-mcast-03.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Layer Two Tunneling Protocol (L2TP) provides a standard method
for tunneling PPP packets. This document describes an extension to
L2TP, in order to have an efficient use of L2TP tunnels within the
context of deploying multicast services whose data will have to be
conveyed by such tunnels.
Table of Contents
1. Introduction................................................2
1.1. Conventions used in this document...........................3
1.2. Terminology.................................................3
2. Motivation for a session-based solution.....................4
3. Control Connection establishment............................4
3.1. Negotiation phase...........................................4
3.2. Multicast Capability AVP (SCCRQ, SCCRP).....................4
4. L2TP multicast session establishment decision...............5
4.1. IGMP states in LNS..........................................5
4.2. Triggering..................................................6
Bourdon Expires September 2003 [Page 1]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
5. L2TP multicast session opening process......................6
5.1. Multicast-Session-Request (MSRQ)............................7
5.2. Multicast-Session-Response (MSRP)...........................8
5.3. Multicast-Session-Established (MSE).........................8
6. Session maintenance and management..........................9
6.1. Multicast-Session-Information (MSI).........................9
6.2. Outgoing Sessions List updates.............................10
6.2.1. New Outgoing Sessions AVP (MSI)............................10
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI)............11
6.2.3. Withdraw Outgoing Sessions AVP (MSI).......................12
6.3. Multicast Packets Priority AVP (MSI).......................12
6.3.1. Global configuration.......................................14
6.3.2. Individual configuration...................................14
6.3.3. Priority...................................................14
7. Multicast session teardown.................................14
7.1. Operations.................................................15
7.2. Multicast-Session-End-Notify (MSEN)........................15
7.3. Result Codes...............................................16
8. Traffic merging............................................16
9. IANA Considerations........................................17
10. Security Considerations....................................17
11. References.................................................18
12. Acknowledgments............................................18
13. Author's Addresses.........................................18
1. Introduction
The deployment of IP multicast-based services may have to deal with
L2TP tunnel engineering. From this perspective, the forwarding of
multicast data within L2TP sessions may impact the throughput of L2TP
tunnels. This proposal aims to reduce this impact by applying
replication mechanism of multicast traffic only when necessary.
The solution described herein provides a mechanism for transmitting
multicast data only once for all the L2TP sessions that have been
established in a tunnel, each multicast group having a dedicated L2TP
session.
Within the context of deploying IP multicast-based services, it is
assumed that the routers of the IP network that embed a L2TP Network
Server (LNS) capability may be involved in the forwarding of
multicast data, towards users who access the network through an L2TP
tunnel. Then the LNS is in charge of replicating the multicast data
for a multicast group G for each L2TP session that is used by a
receiver who has actually subscribed to group G. The solution
described here gives the ability for a LNS to send multicast data
once and make the L2TP Access Concentrator (LAC) perform the traffic
replication. By doing so, it is expected to spare transmission
resources in the core network that supports L2TP tunnels. This
multicast extension to L2TP is designed so that it does not affect
the behavior of L2TP equipment under normal conditions. A solution to
carry multicast data once in a L2TP tunnel is interesting for service
Bourdon Expires September 2003 [Page 2]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
providers since edge devices are aggregating more and more users.
This is particularly true for operators who are deploying xDSL
(Digital Subscriber Line) and cable infrastructures. Therefore, L2TP
tunnels that may be supported by the network will have to carry
multiple redundant multicast data more often. The solution described
in this document applies to downstream traffic exclusively, i.e. data
coming from the LNS towards end-users connected to the LAC. This
downstream multicast traffic is not framed by the LNS but by the LAC,
thus ensuring compatibility for all users in a common tunnel whatever
their framing scheme is.
1.1. Conventions used in this document
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].
1.2. Terminology
Unicast session
This term refers to the definition of "Session", as it is described
in the terminology section of [RFC2661]. (Also: L2TP unicast session)
Multicast session
This term refers to a connection between the LAC and the LNS.
Additional Control Messages and Attribute-Value-Pairs (AVPs) are
defined in this document to open and maintain this connection for the
particular purpose of multicast traffic transportation. This
connection between the LAC and the LNS is intended to convey
multicast traffic only. (Also: L2TP multicast session)
Session
This term is used when there is no need to dissociate multicast from
unicast sessions, and thus designates both. (Also: L2TP session)
M-IGP
Designates a Multicast Interior Gateway Protocol.
(*, G)
Designates a multicast group state, considering the group G and all
sources sending to this group G.
(S, G)
Bourdon Expires September 2003 [Page 3]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
Designates a multicast group state, considering the group G and the
source S sending to this group G.
2. Motivation for a session-based solution
Multicast data have to be seen as a singular flow that potentially
concerns all L2TP sessions already existing in a tunnel. It means
that a given L2TP session can be dedicated for the forwarding of a
unique multicast flow that is addressed to multiple receivers. A
session carrying IP multicast data is independent from the framing
scheme and is therefore compatible with any new framing scheme that
may be supported by the L2TP protocol.
Using a single L2TP session per multicast group G to carry multicast
data is motivated by the following arguments:
- The administrator of the LNS is presumably in charge of the IP
multicast-based services and the related engineering aspects. As
such, he must be capable of filtering multicast flows on a multicast
source basis, on a multicast group basis, and on a user basis (users
who access the network using a L2TP session that terminates in this
LNS).
- Having a L2TP session dedicated for a multicast group gives the
ability to have distinct policies for each group. For instance, it is
possible to allow more bandwidth for some groups, or change the
priority treatment for multicast packets against unicast packets.
- It is not always acceptable nor possible to have multicast
forwarding performed within the network between the LAC and the LNS.
Having the multicast traffic conveyed within a L2TP tunnel ensures a
multicast service between the LNS and end-users, without necessity of
having a multicast capability in the underlying network.
3. Control Connection establishment
3.1. Negotiation phase
The multicast extension capability is negotiated between the LAC and
the LNS during the control connection establishment phase. However,
establishment procedures defined in [RFC2661] remain unchanged. A LAC
indicates its multicast extension capability by using a new AVP, the
"Multicast Capability" AVP. There is no explicit acknowledgement from
the LNS during the control connection establishment phase. Instead,
the LNS is granted to use multicast extension messages to open and
maintain multicast session(s).
3.2. Multicast Capability AVP (SCCRQ, SCCRP)
In order to inform the LNS that a LAC has the ability to handle
multicast sessions, the LAC sends a Multicast Capability AVP during
Bourdon Expires September 2003 [Page 4]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
the control connection establishment phase.
This AVP is sent either in a SCCRQ or a SCCRP control message by the
LAC towards the LNS.
Upon receipt of the Multicast Capability AVP, a LNS may adopt two
distinct behaviors:
1) The LNS does not implement the L2TP multicast extension: the
Multicast Capability AVP is ignored, and the LNS will not initiate
any L2TP-based multicast action.
2) The LNS implements L2TP multicast extensions, and therefore
supports the Multicast Capability AVP: the LNS is granted to send
L2TP specific commands for conveying multicast traffic towards the
LAC.
The multicast capability exclusively refers to the tunnel for which
the AVP has been received during control connection establishment
phase. It SHOULD be possible for a LNS administrator to shut down
L2TP multicast extension features towards one or a set of LAC(s). In
this case, the LNS behavior is similar to 1).
The AVP has the following format:
Vendor ID = to be defined (0 once TBA1 assigned by IANA)
Attribute = TBA1 (16 bits) (Note: to be assigned by IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The M-bit MUST be set to 0, the AVP MAY be hidden (H-bit set to 0 or
1).
The length of this AVP is 6 octets.
4. L2TP multicast session establishment decision
4.1. IGMP states in LNS
The LNS MUST always be at the origin of the creation of a multicast
L2TP session dedicated for the forwarding of IP multicast datagrams
destined to a multicast group.
The router that embeds the LNS feature MUST support IGMPv1
([RFC1112]) or IGMPv2 ([RFC2236]) or IGMPv3 ([RFC3376]) and acts as
an IGMP Querier for every logical interface represented by a L2TP
Bourdon Expires September 2003 [Page 5]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
session. However, the L2TP Multicast Extension is not designed to
take advantage of IGMPv3 source filtering, and is restricted to
multicast group operations.
As a multicast router, the equipment that embeds the LNS function
will be involved in the state maintenance related to the multicast
groups for which receivers have subscribed to, i.e. the maintenance
of an OIL (Outgoing Interface List) for every multicast group G
defined by (*, G) and (S, G) states. The OIL for a given multicast
group G will be partly composed by logical interfaces. All or some of
these logical interfaces will correspond to L2TP unicast sessions in
this context.
Implementing IGMP requires the LNS-capable equipment to create and
maintain OILs. Using these tables, the LNS can build for each
subscribed group within a tunnel a list of the associated L2TP
sessions: the Outgoing Sessions List (OSL). An OSL gives the ability
to identify which L2TP sessions connect users interested in receiving
the traffic corresponding to a given multicast group, and this for
each L2TP tunnel. There is one OSL maintained per L2TP multicast
session (i.e. per multicast group) within an L2TP tunnel. Whenever
the OSL gets empty, the LNS MUST stop sending multicast traffic over
the L2TP multicast session. Then the L2TP multicast session MUST be
torn down as described in Section 7 of this document.
The LAC does not have any IGMP activity; IGMP processing is performed
by the LNS. The LAC is a layer-2 equipment, and is not supposed to
track IGMP messages between users and the LNS in this context.
In order for the LAC to forward the multicast traffic received
through the L2TP multicast session to end-users, the LNS sends to the
LAC the OSL for the related multicast session (see Section 6).
4.2. Triggering
The rules to be enforced by the LNS so as to decide when to open a
dedicated L2TP multicast session for a multicast group SHOULD be
configurable by the LNS administrator. This would typically happen
whenever a number of MULTICAST_SESSION_THRESHOLD receivers/sessions
is reached. This threshold value SHOULD be valued at 2 by default, if
we consider that it is worth opening a dedicated L2TP multicast
session for a multicast group subscribed by two receivers (which
means that two L2TP unicast sessions are concerned).
Reception by the LNS of multicast traffic requested by end-users can
also be taken into account to decide if the associated L2TP multicast
session has to be opened.
5. L2TP multicast session opening process
The opening of an L2TP multicast session is initiated by the LNS. A
three-message exchange is utilized to set up the session. Following
is a typical sequence of events:
Bourdon Expires September 2003 [Page 6]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
LAC LNS
--- ---
(multicast session
triggering)
<- MSRQ
MSRP ->
(Ready to
replicate)
MSE ->
<- ZLB ACK
ZLB ACK is sent if there are no further messages waiting in queue for
that peer.
5.1. Multicast-Session-Request (MSRQ)
Multicast-Session-Request (MSRQ) is a control message sent by the LNS
to the LAC to indicate that a multicast session can be created. The
LNS initiates this message according to the rules mentioned in
section 4.2. It is the first in a three-message exchange used for
establishing a multicast session within a L2TP tunnel.
A LNS MUST NOT send a MSRQ control message if the remote LAC did not
open the L2TP tunnel with the Multicast Capability AVP. The LAC MUST
close the session if it receives a MSRQ control message, while the
L2TP tunnel was not opened with a Multicast Capability AVP.
The following AVPs MUST be present in MSRQ:
Message Type
Assigned Session ID
The following AVP MAY be present in MSRQ:
Random Vector
Maximum BPS
The Maximum BPS value is set by the LNS administrator. However, this
value should be chosen in accordance with the line capabilities of
the end-users. The Maximum BPS value SHOULD NOT be higher than the
highest speed connection for all end-users within the L2TP tunnel.
The associated Message Type AVP is encoded with the values:
Bourdon Expires September 2003 [Page 7]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
Vendor ID = to be defined (0 once TBA2 assigned by IANA)
Attribute Type = 0
Attribute Value = TBA2 (16 bits) (Note: to be assigned by IANA)
The M-bit MUST be set to 0, the H-bit MUST be set to 0.
5.2. Multicast-Session-Response (MSRP)
Multicast-Session-Response (MSRP) is a control message sent by the
LAC to the LNS in response to a received MSRQ message. It is the
second in a three-message exchange used for establishing a multicast
session within a L2TP tunnel.
MSRP is used to indicate that the MSRQ was successful and the LAC
will attempt to reserve appropriate resources to perform multicast
replication for unicast sessions managed in the pertaining control
connection.
The following AVPs MUST be present in MSRP:
Message Type
Assigned Session ID
The following AVP MAY be present in MSRP:
Random Vector
The associated Message Type AVP is encoded with the values:
Vendor ID = to be defined (0 once TBA3 assigned by IANA)
Attribute Type = 0
Attribute Value = TBA3 (16 bits) (Note: to be assigned by IANA)
The M-bit MUST be set to 0, the H-bit MUST be set to 0.
5.3. Multicast-Session-Established (MSE)
Multicast-Session-Established (MSE) is a control message sent by the
LAC to the LNS to indicate that the LAC is ready to receive necessary
multicast information (Section 6) for the group using the newly
created multicast session. It is the third message in the three-
message sequence used for establishing a multicast session within a
L2TP tunnel.
The following AVP MUST be present in MSE:
Message Type
The following AVP MAY be present in MSE:
Bourdon Expires September 2003 [Page 8]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
Sequencing Required
Sequencing will occur only from the LNS to the LAC since a
multicast session is used for downstream purposes only.
The associated Message Type AVP is encoded with the values:
Vendor ID = to be defined (0 once TBA4 assigned by IANA)
Attribute Type = 0
Attribute Value = TBA4 (16 bits) (Note: to be assigned by IANA)
The M-bit MUST be set to 0, the H-bit MUST be set to 0.
6. Session maintenance and management
Once the multicast session is established, the LAC has to be informed
of the L2TP unicast sessions interested in getting the traffic from
the newly-created multicast session, as well as a related optional
priority parameter defined in Section 6.3. To achieve this, a new
control message type is defined: Multicast-Session-Information (MSI).
6.1. Multicast-Session-Information (MSI)
Multicast-Session-Information (MSI) control messages carry AVPs to
keep the OSL synchronised between the LNS and the LAC and to set
optional priority parameter for multicast traffic versus unicast
traffic. MSI may be extended to update the multicast session with
additional parameters as needed.
Each MSI message is specific to a particular multicast session.
Therefore, the control message MUST use the assigned session ID
associated to the multicast session (assigned by the LAC), except for
the case mentioned in 6.3.2.
The associated Message Type AVP is encoded with the values:
Vendor ID = to be defined (0 once TBA5 assigned by IANA)
Attribute Type = 0
Attribute Value = TBA5 (16 bits) (Note: to be assigned by IANA)
The M-bit MUST be set to 0, the H-bit MUST be set to 0.
The following AVPs MUST be present in MSI:
Message Type
The following AVP MAY be present in MSI:
Bourdon Expires September 2003 [Page 9]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
Random Vector
New Outgoing Sessions
New Outgoing Sessions Acknowledgement
Withdraw Outgoing Sessions
Multicast Packets Priority
New Outgoing Sessions, New Outgoing Sessions Acknowledgement,
Withdraw Outgoing Sessions and Multicast Packets Priority are new
AVPs defined in sections 6.2 and 6.3.
6.2. Outgoing Sessions List updates
Whenever a change occurs in the Outgoing Sessions List, the LNS MUST
inform the LAC of that change. The OSL is built upon subscription
reports recorded by the IGMP process running in the LNS (Section
4.1).
The LAC maintains an OSL as a per-group local table transmitted by
the LNS. As for the LNS, the LAC has to maintain an OSL for each L2TP
multicast session within a L2TP tunnel. To update the LAC OSL, the
LNS sends a New Outgoing Sessions AVP for additional(s) session(s) or
sends a Withdraw Outgoing Sessions AVP to remove session(s). All
sessions mentioned in these AVPs MUST be added or removed by the LAC
from the pertaining OSL. The Outgoing Sessions List is identified by
the tunnel ID and the multicast session ID the updating AVP is
referring to.
To update the OSL, the following AVPs are used:
Additional session(s): New Outgoing Sessions AVP
Session(s) removal: Withdraw Outgoing Sessions AVP
These new AVPs MUST be sent in a MSI message.
6.2.1. New Outgoing Sessions AVP (MSI)
The New Outgoing Sessions AVP can only be carried within a MSI
message type. This AVP piggybacks every Session ID to which the
multicast traffic has to be forwarded.
The AVP has the following format:
Vendor ID = to be defined (0 once TBA6 assigned by IANA)
Attribute = TBA6 (16 bits) (Note: to be assigned by IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA6 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bourdon Expires September 2003 [Page 10]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be from 1 to N Session IDs present in the New Outgoing
Sessions AVP. This AVP must be placed in a MSI message and sent after
the establishment of the multicast session to indicate the LAC what
are the initial outgoing sessions, and at any time when one or more
outgoing sessions appear during the multicast session lifetime. Upon
reception of this AVP, the LAC sends a New Outgoing Sessions
Acknowledgment AVP to the LNS to notify that the LAC is ready to
replicate the multicast traffic towards the indicated sessions.
Usage of this AVP is incremental: only new outgoing sessions have to
be listed in the AVP.
The M-bit MUST be set to 1, the AVP MAY be hidden (H-bit set to 0 or
1).
6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI)
The New Outgoing Sessions Acknowledgement AVP can only be carried
within a MSI message type. This AVP informs the LNS that the LAC is
ready to replicate traffic for every Session ID listed within.
The AVP has the following format:
Vendor ID = to be defined (0 once TBA7 assigned by IANA)
Attribute = TBA7 (16 bits) (Note: to be assigned by IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA7 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP must be placed in a MSI message and sent by the LAC towards
the LNS to acknowledge reception of a New Outgoing Sessions list
received in a New Outgoing Sessions AVP from the LNS.
A LNS is allowed to send multicast traffic within the L2TP multicast
session as soon as a New Outgoing Sessions Acknowledgement AVP is
received for the related L2TP multicast session.
A LNS is allowed to stop sending multicast traffic for the related
group within L2TP unicast sessions only when it receives a MSI
Bourdon Expires September 2003 [Page 11]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
message with the New Outgoing Session Acknowledgement AVP, and only
for the unicast Session IDs mentioned in the AVP. The multicast
traffic can use L2TP unicast sessions again when the L2TP multicast
session goes down. From this standpoint, multicast traffic related to
this group SHOULD NOT be conveyed within the L2TP unicast sessions
mentioned in the AVP to avoid duplicate multicast packets.
There can be from 1 to N Session IDs present in the New Outgoing
Sessions Acknowledgement AVP. Session IDs mentioned in this AVP that
have not been listed in a previous New Outgoing Sessions AVP should
be ignored. Non-acknowledged Session IDs MAY be listed in future New
Outgoing Sessions AVPs, but multicast traffic MUST be sent to logical
interfaces associated to these Session IDs as long as these Session
IDs are not acknowledged for replication by the LAC.
The M-bit MUST be set to 1, the AVP MAY be hidden (H-bit set to 0 or
1).
6.2.3. Withdraw Outgoing Sessions AVP (MSI)
The Withdraw Outgoing Sessions AVP is sent whenever there is one or
more withdrawn subscriptions for the related multicast group
(designated by the session ID on which the MSI is sent).
The LAC can stop forwarding multicast traffic to users mentioned in
the AVP for the related group as soon as it receives the MSI message
embedding this Withdraw Target Session AVP.
The AVP has the following format:
Vendor ID = to be defined (0 once TBA8 assigned by IANA)
Attribute = TBA8 (16 bits) (Note: to be assigned by the IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA8 | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be from 1 to N Session IDs present in the Withdraw Outgoing
Sessions AVP. The M-bit MUST be set to 1, the AVP MAY be hidden (H-
bit set to 0 or 1).
6.3. Multicast Packets Priority AVP (MSI)
The Multicast Packets Priority AVP is an optional AVP intended to
provide the LAC with an indication on how to process multicast
Bourdon Expires September 2003 [Page 12]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
traffic against unicast traffic. Even though the LAC behavior is
partially described here, the nature of the traffic (layer-2 frames
for unicast traffic and pure IP packets for multicast traffic) is not
a criteria for enforcing a traffic prioritisation policy. Traffic
processing for the provisioning of a uniformly-framed traffic for the
final user is described is section 8.
Three different behaviors can be adopted:
1) Best effort: the traffic is forwarded from the LAC to the end-user
in the order it comes from the LNS, whatever the type of traffic.
2) Unicast traffic priority: traffic coming down the L2TP unicast
session has priority over traffic coming down the L2TP multicast
session.
3) Multicast traffic priority: traffic coming down the L2TP multicast
session has priority over traffic coming down the L2TP unicast
session.
The priority is encoded as a 16-bit quantity, which can take the
values:
0: Best effort (default)
1: Unicast traffic priority
2: Multicast traffic priority
The AVP has the following format:
Vendor ID = to be defined (0 once TBA9 assigned by IANA)
Attribute = TBA9 (16 bits) (Note: to be assigned by the IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA9 | Priority Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is important to note that the multicast traffic rate can reach up
to Maximum BPS (as indicated in MSRQ). This rate can exceed the
maximum rate allowed for a particular final user. This means that
even with a priority value = 0, the final user might receive
multicast traffic only: unicast packets might be dropped because the
multicast flow overwhelms the LAC forwarding buffer.
The default Priority Value is 0. The M-bit MUST be set to 0, the AVP
MAY be hidden (H-bit set to 0 or 1).
There are two ways of using this AVP: global configuration and
individual configuration.
Bourdon Expires September 2003 [Page 13]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
6.3.1. Global configuration
The Multicast Priority Packet AVP is sent for all L2TP unicast
sessions concerned by a specific multicast group represented by a
L2TP multicast session.
In this case, the AVP is sent in a L2TP MSI control message for the
corresponding multicast session ID (Session ID = L2TP session for the
corresponding multicast group). The priority value applies to all
L2TP unicast sessions to which the multicast group designated by the
L2TP multicast session is intended, as soon as this AVP is received.
6.3.2. Individual configuration
The Multicast Priority Packet AVP is sent for a specific L2TP unicast
session concerned by adopting a specific behavior for both unicast
and multicast traffic. In this case, the AVP is sent in a L2TP MSI
control message for the L2TP unicast session (Session ID = L2TP
session for the concerned user). The priority value applies to the
individual session only, and doesn't affect other individual
sessions. It is important to note that in this case, all multicast
groups carried in L2TP multicast sessions are treated by the LAC the
same way for the concerned user.
This is the only case where a MSI control message can be sent for a
L2TP unicast session.
6.3.3. Priority
It is the responsibility of the network administrator to decide which
behavior to adopt between global or individual configuration, if the
AVP is sent twice (one for a multicast group and one for an
individual user). By default, only the individual configurations
SHOULD be taken into consideration in that case.
Support of the Multicast Packets Priority AVP is optional and SHOULD
be configurable by the LAC administrator if available.
7. Multicast session teardown
A L2TP multicast session should be torn down whenever there are no
longer users interested in. More generally, we can consider that a
multicast session becomes useless as soon as the related OSL has less
than a predefined number of entries, this number being defined by a
threshold.
Multicast session flapping may occur when the number of OSL entries
is oscillating around the threshold, if the same value is used to
trigger the creation or the deletion of an L2TP multicast session.
To avoid this behavior, two methods can be used:
- The threshold value used to determine if the L2TP multicast
session has to be torn down is lower than the
MULTICAST_SESSION_THRESHOLD value;
Bourdon Expires September 2003 [Page 14]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
- The MULTICAST_SESSION_THRESHOLD value is used to determine if
the L2TP multicast session has to be torn down. A multicast session
SHOULD be killed after a period of MULTICAST_SESSION_HOLDTIME seconds
if the corresponding OSL maintains less than
MULTICAST_SESSION_THRESHOLD entries. The MULTICAST_SESSION_HOLDTIME
value is 10 seconds by default, and SHOULD be configurable either by
the LAC or the LNS administrator.
The multicast session can be torn down for multiple reasons,
including specific criteria not described here (can be vendor-
specific).
A multicast session teardown can be initiated either by the LAC or
the LNS. However, multicast session teardown MUST be initiated by the
LNS if the termination decision is motivated by the number of users
interested in receiving the traffic corresponding to a multicast
group.
7.1. Operations
The effective termination of a multicast session is initiated with a
new Multicast-Session-End-Notify (MSEN) control message, sent either
by the LAC or by the LNS.
Following is an example of control messages exchange to terminate a
multicast session:
LAC or LNS LAC or LNS
---------- ----------
(multicast session
termination)
<- MSEN
(Clean up)
ZLB ACK ->
(Clean up)
7.2. Multicast-Session-End-Notify (MSEN)
The Multicast-Session-End-Notify (MSEN) is an L2TP control message
sent by either the LAC or the LNS to request termination of a
specific multicast session within the tunnel. Its purpose is to
inform the peer of the termination and the reason why the termination
occurred. The peer MUST clean up any resources, and does not send
back any indication of success or failure.
As defined in [RFC2661], termination of a control connection will
terminate all sessions managed within, including multicast sessions
if any.
Bourdon Expires September 2003 [Page 15]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
The MSEN message carries a Result Code AVP with an optional Error
Code.
The following AVPs MUST be present in a MSEN message:
Message Type
Result Code
Assigned Session ID
The associated Message Type AVP is encoded with the values:
Vendor ID = to be defined (0 once TBA10 assigned by IANA)
Attribute Type = 0
Attribute Value = TBA10 (16 bits) (Note: to be assigned by IANA)
The M-bit MUST be set to 0, the H-bit MUST be set to 0.
7.3. Result Codes
The following values are the defined result codes for MSEN control
messages:
TBA11 (16 bits) - Session terminated for the reason indicated in
the error code
TBA12 (16 bits) - No multicast traffic for the group
TBA13 (16 bits) - No more receivers
(Note: TBA11, TBA12 and TBA13 to be defined by the IANA)
o The code TBA11 refers to General Error Codes maintained by the
IANA for L2TP.
o The code TBA12 may be used when the LAC detects that no traffic
is coming down the multicast session, or when the LNS doesn't receive
multicast traffic for the related group during a certain period of
time.
o The code TBA13 may be used by the LAC or the LNS when the OSL is
empty.
8. Traffic merging
Both unicast and multicast traffics have to be merged by the LAC in
order to provide properly framed data to the end-user. Multicast
packets are framed by the LAC and transmitted towards the proper end-
user. Methods to achieve this function are not described here, since
it is mostly an implementation specific issue.
All frames conveyed from the LAC to the end-users have to follow the
framing scheme applied for the considered peer to which the traffic
is destined (e.g. the LAC is always aware of the PPP link parameters,
as described in [RFC2661], Section 6.14). It has to be noted that
using L2TP Multicast Extension features is not appropriate for end-
Bourdon Expires September 2003 [Page 16]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
users who have negotiated a sequenced layer-2 connection with the
LNS: while inserting PPP-encapsulated multicast packets in a session,
the LAC cannot modify PPP sequencing performed by the LNS for each
PPP session.
9. IANA Considerations
This document defines:
- 5 new Message Type (Attribute Type 0) Values:
o Multicast-Session-Request (MSRQ) : TBA2
o Multicast-Session-Response (MSRP) : TBA3
o Multicast-Session-Establishment (MSE) : TBA4
o Multicast-Session-Information (MSI) : TBA5
o Multicast-Session-End-Notify (MSEN) : TBA10
- 5 new Control Message Attribute Value Pairs:
o Multicast Capability : TBA1
o New Outgoing Sessions : TBA6
o New Outgoing Sessions Acknowledgement : TBA7
o Withdraw Outgoing Sessions : TBA8
o Multicast Packets Priority : TBA9
- 3 Result Codes for the MSEN message:
o Session terminated for the reason indicated in the
error code : TBA11
o No multicast traffic for the group : TBA12
o No more receivers : TBA13
IANA will assign, register and maintain values for these new
attributes ([RFC3438]).
10. Security Considerations
The extension described in this document does not introduce any
additional security issues as far as the activation of the L2TP
protocol is concerned.
Injecting appropriate control packets in the tunnel towards a LAC to
modify Outgoing Session List and flood end-users with unwanted
multicast traffic is only possible if the control connection is
hacked. As for any reception of illegitimate L2TP control message:
- If the spoofed control message embeds consistent sequence
numbers, next messages will appear out of synch bringing the control
connection to terminate.
- If sequence numbers are inconsistent with current control
connection states, the spoofed control message will be queued or
discarded, as described in [RFC2661] section 5.8.
The activation of the L2TP multicast capability on a LAC could make
the equipment more sensitive to Denial of Service attacks if the
Bourdon Expires September 2003 [Page 17]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
control connection or the related LNS is hacked. The LAC might also
be sensitive to the burden generated by the additional replication
work.
As mentioned in [RFC2661] section 9.2, securing L2TP requires that
the underlying transport makes encryption, integrity and
authentication services available for all L2TP traffic, including
L2TP multicast traffic (control and data).
11. References
[RFC1112] S. Deering, "Host Extensions for IP Multicasting",
RFC 1112, August 1989.
[RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] W. Fenner, "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunneling Protocol "L2TP" ",
RFC2661, August 1999.
[RFC3376] B. Cain et. al., "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3438] W. Townsley, "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA)
Considerations Update", RFC 3438, December 2002.
12. Acknowledgments
Thanks to Christian Jacquenet for all the corrections done on this
document and his precious advice, Pierre Levis for his contribution
about IGMP, Francis Houllier for PPP considerations and Xavier Vinet
for his input about thresholds. Many thanks to W. Mark Townsley for
his highly valuable input on protocol definition.
13. Author's Addresses
Gilles Bourdon
France Telecom R&D
38-40, rue du General Leclerc
92794 Issy les Moulineaux Cedex 9 - FRANCE
Bourdon Expires September 2003 [Page 18]
Internet Draft draft-ietf-l2tpext-mcast-03.txt March 2003
Phone: +33 1 4529-4645
Email: gilles.bourdon <at> francetelecom.com
Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bourdon Expires September 2003 [Page 19]
3 Mar 2003 23:32
draft-luo-l2tpext-l2vpn-signaling-01.txt
Wei Luo <luo <at> cisco.com>
2003-03-03 22:32:47 GMT
2003-03-03 22:32:47 GMT
FYI, enclosed is the latest draft-luo-l2tpext-l2vpn-signaling-01.txt. It should be available from IETF website as well. Your comments are appreciated. ---Wei
Network Working Group Wei Luo
Internet Draft Cisco Systems, Inc.
February 2003
L2VPN Signaling Using L2TPv3
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Layer 2 Tunneling Protocol (L2TPv3) provides a standard method
for setting up and managing L2TP sessions to tunnel a variety of L2
protocols. One of the reference models supported by L2TPv3 describes
the use of an L2TP session to cross-connect two Layer 2 circuits
attached to a pair of peering LACs. A cross-connect is a basic form
of Layer 2 Virtual Private Networks (L2VPNs). This document
describes mechanisms which utilize the building blocks that L2TP
provides to construct different types of L2VPNs.
Specification of Requirements
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 [RFC 2119].
Luo [Page 1]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
Table of Contents
Status of this Memo.......................................... 1
1. Introduction.............................................. 3
2. Network Reference Model and L2VPN Applications............ 3
3. Forwarders and End Identifiers............................ 4
4. L2TP Control Messages..................................... 5
5. Existing AVPs for L2VPNs.................................. 5
5.1 Router ID............................................. 5
5.2 Pseudowire Capabilities List.......................... 5
5.3 Pseudowire Type....................................... 5
5.4 Pseudowire Control Encapsulation...................... 6
5.5 Circuit Status........................................ 6
5.6 Remote End ID......................................... 6
6. New AVPs for L2VPN........................................ 6
6.1 Local End ID.......................................... 6
7. Pseudowire Tie Detection.................................. 7
8. L2VPN Signaling Procedures................................ 8
8.1 Overview.............................................. 8
8.2 Generic Algorithm..................................... 8
8.3 Application-specified Processing...................... 12
8.3.1 Cross-connect.................................... 12
8.3.2 Virtual Private LAN Service...................... 12
8.3.3 Colored Pools.................................... 13
9. BGP-based Auto-discovery.................................. 13
9.1 Common L2VPN Addressing and NLRI Encoding............. 13
9.2 AFI/SAFI and BGP Capabilities......................... 14
9.3 Route Targets......................................... 14
10. Heterogeneous L2VPN Deployment........................... 15
11. Intellectual Property Notice............................. 16
12. IANA Considerations...................................... 16
13. Security Considerations.................................. 16
14. Acknowledgement.......................................... 16
Luo [Page 2]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
15. References............................................... 16
16. Authors' Address......................................... 17
1. Introduction
[L2TPv3] defines a dynamic tunneling mechanism to carry multiple L2
protocols besides PPP (as originally defined in [RFC 2661]), over a
packet-based network. The baseline protocol supports various types
of applications, which has been hightlighted in the different L2TP
reference models in [L2TPv3]. L2VPN applications are typically in
the scope of the LAC-LAC reference model.
This document discusses the commonality as well as difference among
L2VPN applications with respect to utilizing L2TPv3 as the signaling
protocol. It also specifies the necessary information required by
BGP-based auto-discovery for the integration with the L2TPv3-based
signaling protocol. Other auto-discovery mechanisms are left for
future studies.
The acronym "L2TP" refers to L2TPv3 or L2TP in general in this
document.
2. Network Reference Model and L2VPN Applications
In the LAC-LAC reference mode, a LAC serves as a cross-connect
between attachment circuits and L2TP sessions. Each L2TP session
acts as an emulated circuit, also known as pseudowire.
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |...[packet network]...| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
In a simple cross-connect application, an attachment circuit is
directly bound to a pseudowire. It's a one-to-one mapping. Traffic
received from the attachment circuit on a local LAC is forwarded to
the remote LAC through the pseudowire. When the remote LAC receives
traffic from the pseudowire, it forwards the traffic to the
corresponding attachment circuit on its end. The forwarding decision
is based on the attachment circuit or pseudowire demultiplexing
identifier respectively.
Luo [Page 3]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
With Virtual Private LAN Service (VPLS), one or more attachment
circuits and pseudowires are connected to a Virtual Switching
Instance (VSI) on a LAC. A single pseudowire is used to connect a
pair of VSIs on two peering LACs. Traffic received from an
attachment circuit or a pseudowire is first forwarded to the
corresponding VSI based on the attachment circuit or pseudowire
demutiplexing identifier. The VSI performs additional lookup to
determine where to further forward the traffic.
[L2 FW] describes an L2VPN application called Colored Pools, which is
essentially made of a network of point-to-point cross-connect. The
data forwarding perspective is identical to the cross-connect
application, while constructing Colored Pools involves more
complicated signaling procedures.
3. Forwarders and End Identifiers
As described in [L2 FW], a pseudowire is bound to a "forwarder",
which in turn binds to one or more attachment circuits. For
different L2VPN applications, different types of forwarders are
defined.
An End Identifier is assigned to each forwarder on a given LAC that
supports L2VPN applications. It must be unique in the context of the
LAC.
In simple cross-connect, each individual attachment circuit is a
forwarder, and provisioned with an End ID value. Without any auto-
discovery, each attachment circuit needs to be manually provisioned
with the remote Router ID and the End ID of the remote attachment
circuit. The End ID value for an attachment circuit may be an
arbitrary integer or a descriptive string.
In VPLS, each VSI is a forwarder, and provisioned with an End ID
value. Without any auto-discovery, each VSI needs to be manually
provisioned with its remote LAC addresses and the End IDs of the
remote VSIs. The End ID value for a VSI may be the VPN ID of the
VPLS domain.
In Colored Pools, each pool is a forwarder, and provisioned with an
End ID value. Without any auto-discovery, each pool needs to be
manually provisioned with its remote LAC addresses and the End IDs of
the remote pools. The End ID value for a pool may be an arbitrary
integer or a descriptive string.
Luo [Page 4]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
4. L2TP Control Messages
L2TP defines two sets of session management procedures: Incoming Call
and Outgoing Call. Even though it's entirely possible to use the
Outgoing Call procedures to signaling L2VPNs, the Incoming Call
procedures has some advantages in terms of the relevance of semantics
and being able to offer moderate capability negotiation between two
LCCEs. [PWE3L2TP] gives more details on why Incoming Call is more
appropriate for setting up pseudowires.
The signaling procedures for L2VPNs described in the following
sections are all based on the Incoming Call procedures.
5. Existing AVPs for L2VPNs
Besides the AVPs required to establish and manage control connections
and sessions, the following AVPs defined in [L2TPv3] are directly
relevant to L2VPN applications.
5.1 Router ID
The Router ID sent in SCCRQ and SCCRP during control connection setup
establishes the unique identity of each LAC.
5.2 Pseudowire Capabilities List
The Pseudowire Capabilities List sent in SCCRQ and SCCRP indicates
the pseudowire types supported by the sending LAC. It merely serves
as an advertisement to the receiving LAC. Its content should not
affect the control connection setup.
Before a local LAC initiates a session of a particular pseudowire
type to a remote LAC, it MUST examine whether the remote LAC has
advertised such a capability in this AVP, and SHOULD NOT attempt to
initiate the session if the intended pseudowire type is not supported
by the remote LAC.
5.3 Pseudowire Type
The Pseudowire Type sent in ICRQ signals the intended pseudowire type
to the receiving LAC. The receiving LAC checks it against its local
pseudowire capability list. If it finds a match, it responds with an
ICRP without a Pseudowire Type AVP, which implicitly acknowledges its
acceptance of the intended pseudowire. If it does not find a match,
Luo [Page 5]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
it MUST respond with a CDN with an "unsupported pseudowire type"
result code.
5.4 Pseudowire Control Encapsulation
The Pseudowire Control Encapsulation can be sent in ICRQ, ICRP, and
ICCN. If the receiving LAC supports the specified control
encapsulation, it MUST include it in its data packets sent to the
sending LAC. Otherwise, it MUST reject the connection by sending a
CDN to the sending LAC.
5.5 Circuit Status
The Circuit Status is sent in both ICRQ and ICRP to inform the
receiving LAC about the circuit status on the sending LAC. It can
also be sent in ICCN and SLI to update the status.
5.6 Remote End ID
The Remote End ID sent in ICRQ instructs the receiving LAC to bind
the proposed pseudowire to the forwarder that has been assigned with
the encoded End Identifier value.
6. New AVPs for L2VPN
6.1 Local End ID
The Local End ID AVP, Attribute Type TBA, encodes the End Identifier
value of the forwarder to be bound to the proposed pseudowire on the
sending LAC. The Local End ID AVP may also be used in conjunction
with the Remote End ID AVP to detect session-level ties. When it's
omitted in the control messages, it's assumed that it has the same
value as the Remote End ID.
The Attribute Value field for this AVP has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA | End ID ... (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Luo [Page 6]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
The End Identifier field is a variable-length field whose value is
unique for a given LCCE. This AVP MAY be present in ICRQ.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6
plus the length of the End Identifier value.
7. Pseudowire Tie Detection
Conceivably in the LAC-LAC network reference model, as either LAC may
initiate a session to another LAC at any time, they could end up
initiating a session to each other simultaneously.
In order to avoid setting up duplicated pseudowires between two
forwarders, each LAC must be able to independently detect such a
pseudowire tie. The following procedures need to be followed to
detect a tie:
If both Remote End ID and Local End ID are present in ICRQ, the
receiving LAC compares them with the Remote End ID and Local End ID,
in reverse order, encoded in the ICRQ it has already sent to the
sending LAC. If the received Remote End ID matches the sent Local
End ID and the received Local End ID matches the sent Remote End ID,
a tie is detected.
If only Remote End ID is present in ICRQ, the Local End ID is assumed
to have the same value as the Remote End ID. The receiving LAC
compares the received Remote End ID with the Local End ID, encoded in
the ICRQ it has already sent to the sending LAC. If the Local End ID
in this ICRQ is also omitted, then the Remote End ID is compared. If
they match, a tie is detected.
Once a tie has been discovered, the standard L2TP tie breaking
procedure is employed to disconnect the duplicated pseudowire.
Luo [Page 7]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
8. L2VPN Signaling Procedures
8.1 Overview
Assume a LAC assigns an End ID to one of its local forwarders, and
knows it needs to set up a pseudowire to a remote forwarder on a
remote LAC that has a certain End ID. This knowledge can be obtained
either through manual configuration or some auto-discovery procedure.
Before establishing the intended pseudowire, each pair of peering
LACs exchanges control connection messages to establish a control
connection. Each advertises its supported pseudowire types in the
Pseudowire Capabilities List AVP.
After the control connection is established, the local LAC examines
whether the remote LAC supports the pseudowire type it intends to set
up. Only if the remote LAC supports the intended pseudowire type, it
should initiate a pseudowire connection request.
When the local LAC receives an ICRQ for a pseudowire connection, it
examines the Remote End ID encoded in the ICRQ to determine the
following:
- whether it has a local forwarder assigned with an End ID value
specified in the Remote End ID,
- whether the remote LAC is allowed to connect with this local
forwarder.
If both conditions are met, it sends an ICRP to the remote LAC to
accept the connection request. If either of the two conditions
fails, it sends a CDN to the remote LAC to reject the connection
request.
8.2 Generic Algorithm
Despite the apparent disparity among different L2VPN applications, a
common set of signaling procedures can be defined.
Each LAC first forms a list, SOURCE_FORWARDERS, consisting of all
local forwarders of a given VPN. Then it puts all local forwarders
that need to be interconnected and all remote forwarders of the same
VPN into another list, TARGET_FORWARDERS. The formation of the
network topology depends on the content in the SOURCE_FORWARDERS and
TARGET_FORWARDERS list. These two lists can be constructed by manual
configuration and/or some auto-discovery procedure.
Luo [Page 8]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
The following algorithm is used to set up pseudowires among all the
forwarders that intend to be interconnected by iterating through each
source and target forwarder. An L2VPN is formed upon finishing the
algorithm in every LAC participating in L2VPN.
SOURCE_FORWARDERS TARGET_FORWARDERS
s1: <Router ID, End ID> t1: <Router ID, End ID>
s2: <Router ID, End ID> t2: <Router ID, End ID>
s3: <Router ID, End ID> t3: <Router ID, End ID>
... ...
1. Pick the next forwarder, from SOURCE_FORWARDERS. If no
forwarder is available for processing, the processing is
complete.
2. Pick the next forwarder, from TARGET_FORWARDERS. If no
forwarder is available for processing, go back to step 1.
3. If the two forwarders are associated with different Router IDs,
a pseudowire must be setup between them. Proceed to step 6.
4. Compare the End ID values of the two forwarders, if they match,
the source and target forwarders are the same, so no more
action is necessary. Go back to step 2.
5. As the source and target forwarders both reside on the local
LAC, no pseudowire is needed. LAC simply creates a local
cross-connect between the two forwarders. Go back to step 2.
6. As the source and target forwarders reside on different LACs,
a pseudowire must be established between them. LAC first
examines if the source forwarder has already established a
pseudowire to the target forwarder. If so, go back to step 2.
7. If no pseudowire is already established between the source and
target forwarders, the local LAC obtains the address of the
remote LAC, and establishes a control connection to the remote
LAC if one does not already exist.
8. The local LAC sends an ICRQ to the remote LAC. The End IDs of
source and target forwarders are encoded as the Local End ID
and Remote End ID respectively.
9. If the local LAC receives a response corresponding to the
ICRQ it just sent, proceed to step 10. Otherwise, if the
local LAC receives an ICRQ from the same remote LAC, proceed
to step 11.
Luo [Page 9]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
10. The local LAC receives a response from the remote LAC. If
it's a CDN, go back to step 2. If it's an ICRP, the local
LAC binds the source forwarder to the pseudowire and sends
an ICCN to the remote LAC, go back to step 2.
11. If the local LAC receives an ICRQ from the same remote LAC,
it needs to perform session tie detection, as described in
Section 7. If a session tie is detected, it performs tie
breaking.
12. If it lost in tie breaking, the local LAC sends a CDN with
the result code that indicates the disconnection is due to
losing tie breaker. Proceed to step 14.
13. If it won in tie breaking, the local LAC ignores the remote
LAC's ICRQ (note that the L2TP reliable transport confirms
receipt of the message with any legitimate control message
even though it doesn't respond to the ICRQ), and continues
waiting for the response from the remote LAC. Go to step 10.
14. The local LAC determines whether it should accept the
connection request, as described in the section 8.1.
If it accepts the ICRQ, it sends an ICRP to the remote LAC.
15. The local LAC receives a response from the remote LAC. If
it's a CDN, go back to step 2. If it's an ICCN, the local
LAC binds the source forwarder to the pseudowire, go back
to step 2.
The following diagram illustrate the above procedures:
Luo [Page 10]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
---------> Pick Next
| Source Forwarder
| |
| |
| v N
| Found Source Forwarder? ----------> End
| |
| Y |
| v
| Pick Next <--------------------------------
| Target Forwarder |
| | |
| | |
| N v |
-------- Found Target Forwarder? |
| |
Y | |
v Y Y |
Same Router ID? -----------> Same End ID? -------|
| | |
N | N | |
| v |
| Create Local -------|
v Cross-connect |
Pseudowire Already Y |
Established Between -------------------------------|
Source and Target? |
| |
N | |
v |
Local Initiates Pseudowire |
Connection Request to Remote |
| |
| |
v |
-------> Local Wait for Message |
| ----- from Remote -------------- |
| | | |
| | | |
| v v |
| Local Receives Pseudowire Local Receives Pseudowire |
| Connection Request Connection Response |
| from Remote from Remote |
| | | |
| | | |
| v v N |
| Perform Pseudowire Connection Accepted? --------|
| Tie Detection | |
Luo [Page 11]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
| | Y | |
| | v |
| | Local Binds Source ---------|
| | Forwarder to Pseudowire |
| | |
| v N N |
| Tie Detected? -----> Accept Remote -----> Reject ------|
| | Connection Request? Remote Request |
| Y | ^ | |
| v | | Y |
| Perform Tie Breaking | ------> Local Binds ----
| | | Source Forwarder
| | | to Pseudowire
| v N |
| Won Tie Breaking? ------> Disconnect
| | Local Connection
| Y |
| v
------ Ignore Remote
Connection Request
8.3 Application-specified Processing
8.3.1 Cross-connect
When a LAC learns the remote Router ID and remote End ID, it may
start the signaling right away or wait for the circuit status of the
local attachment circuit to become active.
After the pseudowire has been successfully established, a LAC binds
the attachment circuit to the pseudowire.
8.3.2 Virtual Private LAN Service
A VSI is a forwarder in VPLS and consists of a number of attachment
circuits and a number of pseudowires. A LAC may have multiple VSIs.
When a LAC learns the remote Router IDs and remote End IDs, it may
start the signaling right away or wait for the first attachment
circuit to join the local VSI.
After the pseudowire has been successfully established, a LAC binds
the VSI to the pseduowire by making the pseudowire a member link of
the bridging domain defined by the VSI.
Luo [Page 12]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
8.3.3 Colored Pools
In the LAC-LAC network reference model, a remote system may have
multiple physical or logical attachment circuits, such as Frame Relay
DLCIs attached to a LAC, which form a "pool" of attachment circuits.
Each pool corresponds to a particular remote system, and is
associated with a particular VPN. If there are multiple remote
systems of the same VPN attached to a LAC, the LAC will have multiple
pools associated with the same VPN.
Each pool is provisioned with an End ID that differentiates itself
from other forwarders residing in the same LAC, and a "color", which
represents a particular VPN. The format of "color" can be a VPN ID.
A VPN ID can be an unsigned integer or a structured numeric value.
If pools with a certain color need to be connected in a full-mesh
fashion, a pseudowire is created between every pair of pools except
the pools residing on the same LAC, and the pseudowire is bound to an
unused attachment circuit from each pool. For pools on the same LAC,
a local cross-connect is formed to bind two attachment circuits.
9. BGP-based Auto-discovery
The BGP-based auto-discovery specified in this document is similar to
the schemes described in [BGPVPN] and [LDPVPN], but further
optimized. Although this mechanism is only discussed in the L2TP
context, it's conceivably useful for LDP-based L2VPN signaling as
well.
9.1 Common L2VPN Addressing and NLRI Encoding
As outlined in Section 3, each forwarder is assigned with an End
Identifier value. An End ID is locally significant and unique
regardless what type of forwarder it's associated with. A Router ID
is a 32-bit global unique value. A Common L2VPN Address is defined
as the concatenation of Router ID and End ID.
The Network Layer Reachability Information (NLRI) for BGP
Multiprotocol Extension [RFC 2858] is encoded as one or more tuples
of the form <length, prefix>:
- Length: 1 octet
The Length field indicates the length in bits of the common
L2VPN address.
- Prefix: variable-length
Luo [Page 13]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
The Prefix fields carry the Common L2VPN Address. As the
Router ID is 32 bits in length, the maximum length of the
End ID is 223 bits, which is rounded to 27 whole octets.
When using BGP-based auto-discovery, care needs to be taken to ensure
the End ID values assigned to the local forwarders do not exceed the
maximum length allowed.
Unlike the NLRI encoding described in [BGPVPN] and [LDPVPN], the
Common L2VPN Addressing scheme uses a single format for all L2VPN
applications, and no Route Distinguisher is needed to guarantee the
uniqueness of the prefix, as a Common L2VPN Address is globally
unique by definition.
9.2 AFI/SAFI and BGP Capabilities
An AFI, to be assigned by IANA, is used for all L2VPN applications.
When L2VPN applications choose to use the Common L2VPN Addressing
scheme, an SAFI, to be assigned by IANA, is used to identify that the
NLRI carried in BGP has such an address format.
In order for two BGP speakers to exchange Common L2VPN NLRI, they
MUST use the negotiation scheme defined in [RFC 2842] to ensure that
both of them are capable of processing such NLRI correctly. This is
done by using the Capability Code 1 for Multiprotocol Extensions, and
the Capability Value containing the AFI and SAFI specified in this
document. The format of the Capabilities parameter is defined in
[RFC 2858].
9.3 Route Targets
If a forwarder wishes to be discovered via BGP, it needs to create a
Common L2VPN Address, and associate the address with one or more
Route Target (RT) Extended Community attributes [BGPEXT]. These
attributes are carried in BGP as part of the Path Attributes, along
with the LAC itself as the BGP next hop.
RTs are used in BGP to control the NLRI distribution. Each BGP
speaker can define a set of distribution policies using RTs to
control how addresses are advertised and learnt, thereby governing
the formation of the L2VPN network topology.
To form a full mesh among the forwarders that belong to the same VPN,
each forwarder is configured with the same RT value as both the
"export RT" and "import RT". This distribution policy will allow
these forwarders to be visible to all BGP speakers having this
Luo [Page 14]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
policy. Therefore, the L2VPN signaling will set up a full mesh of
pseudowires among these forwarders using the algorithm described the
previous section.
Sometimes, a hub-and-spoke L2VPN network is desired. This can be
achieved by using two different RTs for distribution processing,
where one stands for "hub" and the other stands for "spoke". On the
hub LAC, the "hub" RT is assigned to local forwarders as the "export
RT", and the hub LAC is configured to "import" only the Common L2VPN
addresses that have the "spoke" RT. On the spoke LAC, the "spoke" RT
is assigned to local forwarders as the "export RT", and the spoke LAC
is configured to "import" only the Common L2VPN addresses that have
the "hub" RT. This distribution policy will result in (1) spoke LACs
only seeing the forwarders configured on the hub LAC, and (2) a hub
LAC seeing all forwarders configured on every spoke LAC. The L2VPN
signaling then sets up pseudowires that form the hub-and-spoke
topology.
A more complex topology is partial mesh. It can be done by using a
set of "import RTs" and "export RTs" for distribution processing.
10. Heterogeneous L2VPN Deployment
Often there is more than one form of L2VPN application required in a
network. For example, an individual attachment circuit on one LAC
needs to be connected to a VSI or Colored Pool on another LAC by a
pseudowire. In such a case, different L2VPN applications are
deployed concurrently and different types of forwarders are inter-
connected by pseudowires.
The use of Common L2VPN Addressing makes this mix-and-match L2VPN
deployment scenario feasible and easy to manage. As forwarders are
addressed in the same fashion despite different forwarding behaviors
that each may have, a common set of signaling and auto-discovery
procedures can be implemented for a heterogeneous L2VPN deployment.
In addition, the forwarding behavior of each forwarder is determined
by its local characteristics, not those of its peer forwarder. This
gives great flexibility to deploy a heterogeneous L2VPN.
Luo [Page 15]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
11. Intellectual Property Notice
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
12. IANA Considerations
This document defines a new L2TP AVP and a pair of AFI/SAFI to be
maintained by the IANA.
13. Security Considerations
The signaling procedures described in this document does not incur
additional security considerations that L2TP already provisions.
14. Acknowledgement
Many thanks to Mark Townsley, Jed Lau and Dmitry Bokotey for their
review and insightful feedback.
15. References
[RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)",
RFC 2661, August 1999.
[L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol (version3)",
draft-ietf-l2tpext-l2tp-base-04.txt, November 2002
[L2 FW] L. Andersson et. al., "PPVPN L2 Framework",
draft-ietf-ppvpn-l2-framework-00.txt, August 2002
[PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3",
draft-townsley-pwe3-l2tpv3-00.txt, June 2002
[BGPVPN] H. Ould-Brahim et. al. "Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs",
draft-ietf-ppvpn-bgpvpn-auto-03.txt, August 2002
[LDPVPN] E. Rosen, "LDP-based Signaling for L2VPNs",
draft-rosen-ppvpn-l2-signaling-02.txt, September 2002
[RFC 2858] T. Bates et. al., "Multiprotocol Extensions for BGP-4",
Luo [Page 16]
Internet Draft draft-luo-l2tpext-l2vpn-signaling-01.txt February 2003
RFC 2858, June 2000
[RFC 2842] R. Chandra et. al., "Capabilities Advertisement with
BGP-4", RFC2842, May 2000
[BGPEXT] S. Sangli et. al., "BGP Extended Communities Attribute",
draft-ietf-idr-bgp-ext-communities-05.txt, May 2002
16. Authors' Address
Wei Luo
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: luo <at> cisco.com
Luo [Page 17]
13 Mar 2003 10:05
Re: Ns in ZLB ACK
Motonori Shindo <mshindo <at> mshindo.net>
2003-03-13 09:05:26 GMT
2003-03-13 09:05:26 GMT
Venkatesan, What was the Nr of the HELLO sent by LNS? If it was 10, then LAC sending ZLB with Ns = 40 looks violating the spec. Even if it is the case, packet with Ns = 10 will be retransmitted by LAC and make it to the LNS eventually, and tere will be no significant effect; it is just one waste packet sent by LAC. If it ended up with something more catastrophic, then implementation at either side must be broken. Regards, From: Venkatesan Pradeep <Venkatesan.Pradeep <at> cosinecom.com> Subject: [L2tpext] Ns in ZLB ACK Date: Fri, 14 Feb 2003 18:11:51 -0800 > I was testing an LNS using a Cisco LAC (IOS 12.2(T)) and observed a > problem with the Ns in ZLB ACKs sent by the LAC. The LNS was being > stress tested and we were seeing packet loss on it. The LNS had > advertised a window of 20 and the next expected seq was 10. The LAC > had sent packets with Ns = 10 thru Ns = 29 and 10 more were queued > for transmission. The first packet (Ns = 10) didn't make it to the > LNS. The LNS sent a HELLO packet and the LAC responded with > a ZLB ACK with Ns = 40. > > The LNS discarded the ZLB because it was outside its window. It looks > like the LAC increments the sequence number right after queueing the > packets for transmission and is using that for the ZLB. > > I think that the LNS was right in rejecting the ZLB. Am I correct?. > If so, what should the Ns in the ZLB be in this scenario? > Ns = 29: This will make sure that it is within the LNS' window but > given that a non-ZLB packet with Ns=29 had been transmitted, > the next packet (ZLB or not) should have Ns=30 > Ns = 30: This will satisfy the Ns increment rule but the packet will > be outside the LNS' window. > > Thanks, > > Pradeep.
13 Mar 2003 20:49
RE: Ns in ZLB ACK
Venkatesan Pradeep <Venkatesan.Pradeep <at> cosinecom.com>
2003-03-13 19:49:40 GMT
2003-03-13 19:49:40 GMT
The Nr was 10. And yes, if the LAC retransmits got thru to the LNS then
then we were ok. However, if they didn't reach in time the tunnel was
brought down (after the LNS' max retransmission period expired).
Pradeep.
-----Original Message-----
From: Motonori Shindo [mailto:mshindo <at> mshindo.net]
Sent: Thursday, March 13, 2003 1:05 AM
To: Venkatesan Pradeep
Cc: l2tpext <at> ietf.org
Subject: Re: [L2tpext] Ns in ZLB ACK
Venkatesan,
What was the Nr of the HELLO sent by LNS? If it was 10, then LAC
sending ZLB with Ns = 40 looks violating the spec. Even if it is the
case, packet with Ns = 10 will be retransmitted by LAC and make it to
the LNS eventually, and tere will be no significant effect; it is just
one waste packet sent by LAC. If it ended up with something more
catastrophic, then implementation at either side must be broken.
Regards,
From: Venkatesan Pradeep <Venkatesan.Pradeep <at> cosinecom.com>
Subject: [L2tpext] Ns in ZLB ACK
Date: Fri, 14 Feb 2003 18:11:51 -0800
> I was testing an LNS using a Cisco LAC (IOS 12.2(T)) and observed a
> problem with the Ns in ZLB ACKs sent by the LAC. The LNS was being
> stress tested and we were seeing packet loss on it. The LNS had
> advertised a window of 20 and the next expected seq was 10. The LAC
> had sent packets with Ns = 10 thru Ns = 29 and 10 more were queued
> for transmission. The first packet (Ns = 10) didn't make it to the
> LNS. The LNS sent a HELLO packet and the LAC responded with
> a ZLB ACK with Ns = 40.
>
> The LNS discarded the ZLB because it was outside its window. It looks
> like the LAC increments the sequence number right after queueing the
> packets for transmission and is using that for the ZLB.
>
> I think that the LNS was right in rejecting the ZLB. Am I correct?.
> If so, what should the Ns in the ZLB be in this scenario?
> Ns = 29: This will make sure that it is within the LNS' window but
> given that a non-ZLB packet with Ns=29 had been transmitted,
> the next packet (ZLB or not) should have Ns=30
> Ns = 30: This will satisfy the Ns increment rule but the packet will
> be outside the LNS' window.
>
> Thanks,
>
> Pradeep.
18 Mar 2003 05:07
Re: Ns in ZLB ACK
Motonori Shindo <mshindo <at> mshindo.net>
2003-03-18 04:07:59 GMT
2003-03-18 04:07:59 GMT
Venkatesan, Then, LAC sending ZLB ACK with Ns = 40 and the tunnel torn down are two separate issues (I mean, what triggered the tunnel down is unlikely to be such a ZLB ACK sent by LAC). I guess the tunnel was torn down simply because either either side was too heavily loaded and wasn't able to keep up. Going back to your original question, any Ns in ZLB sent by LAC is legitimate as long as it is within the window size advertised by the peer, because ZLB doesn't consume sequencing number space and has no significance per se. If Ns in ZLB has no significance, then is ZLB subject to a window-based flow control? I think it's up to the receiving side. Some implementation may enforce the flow control on ZLB, and some may not. Therefore, it's safe to assume that the peer enforces a flow control even for ZLB, and should not send ZLB with Ns exceeding the advertised window at any time for the sake of better interoperability. In your example, Ns = 29 is OK but Ns = 30 is not. Regards, From: Venkatesan Pradeep <Venkatesan.Pradeep <at> cosinecom.com> Subject: RE: [L2tpext] Ns in ZLB ACK Date: Thu, 13 Mar 2003 11:49:40 -0800 > The Nr was 10. And yes, if the LAC retransmits got thru to the LNS then > then we were ok. However, if they didn't reach in time the tunnel was > brought down (after the LNS' max retransmission period expired). > > Pradeep. > > -----Original Message----- > From: Motonori Shindo [mailto:mshindo <at> mshindo.net] > Sent: Thursday, March 13, 2003 1:05 AM > To: Venkatesan Pradeep > Cc: l2tpext <at> ietf.org > Subject: Re: [L2tpext] Ns in ZLB ACK > > > Venkatesan, > > What was the Nr of the HELLO sent by LNS? If it was 10, then LAC > sending ZLB with Ns = 40 looks violating the spec. Even if it is the > case, packet with Ns = 10 will be retransmitted by LAC and make it to > the LNS eventually, and tere will be no significant effect; it is just > one waste packet sent by LAC. If it ended up with something more > catastrophic, then implementation at either side must be broken. > > Regards, > > From: Venkatesan Pradeep <Venkatesan.Pradeep <at> cosinecom.com> > Subject: [L2tpext] Ns in ZLB ACK > Date: Fri, 14 Feb 2003 18:11:51 -0800 > > > I was testing an LNS using a Cisco LAC (IOS 12.2(T)) and observed a > > problem with the Ns in ZLB ACKs sent by the LAC. The LNS was being > > stress tested and we were seeing packet loss on it. The LNS had > > advertised a window of 20 and the next expected seq was 10. The LAC > > had sent packets with Ns = 10 thru Ns = 29 and 10 more were queued > > for transmission. The first packet (Ns = 10) didn't make it to the > > LNS. The LNS sent a HELLO packet and the LAC responded with > > a ZLB ACK with Ns = 40. > > > > The LNS discarded the ZLB because it was outside its window. It looks > > like the LAC increments the sequence number right after queueing the > > packets for transmission and is using that for the ZLB. > > > > I think that the LNS was right in rejecting the ZLB. Am I correct?. > > If so, what should the Ns in the ZLB be in this scenario? > > Ns = 29: This will make sure that it is within the LNS' window but > > given that a non-ZLB packet with Ns=29 had been transmitted, > > the next packet (ZLB or not) should have Ns=30 > > Ns = 30: This will satisfy the Ns increment rule but the packet will > > be outside the LNS' window. > > > > Thanks, > > > > Pradeep.
31 Mar 2003 06:49
Re: Welcome to the "L2tpext" mailing list
СëÇò <lijieking <at> 163.com>
2003-03-31 04:49:38 GMT
2003-03-31 04:49:38 GMT
> Welcome to the L2tpext <at> ietf.org mailing list! > > To post to this list, send your email to: > > l2tpext <at> ietf.org > > General information about the mailing list is at: > > https://www1.ietf.org/mailman/listinfo/l2tpext > > ************************************************************************** > > > Note Well > > All statements related to the activities of the IETF and addressed to > the IETF are subject to all provisions of Section 10 of RFC 2026, > which grants to the IETF and its participants certain licenses and > rights in such statements. Such statements include verbal statements > in IETF meetings, as well as written and electronic communications > made at any time or place, which are addressed to > > * the IETF plenary session, > * any IETF working group or portion thereof, > * the IESG, or any member thereof on behalf of the IESG, > * the IAB or any member thereof on behalf of the IAB, > * any IETF mailing list, including the IETF list itself, any > working > group or design team list, or any other list functioning > under IETF > auspices, > * the RFC Editor or the Internet-Drafts function > > Statements made outside of an IETF meeting, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not subject to these provisions. > > > ************************************************************************** > > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://www1.ietf.org/mailman/options/l2tpext/lijieking%40163.com > > You can also make such adjustments via email by sending a message to: > > L2tpext-request <at> ietf.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > 77020919 > > If you forget your password, don't worry, you will receive a monthly > reminder telling you what all your ietf.org mailing list passwords > are, and how to unsubscribe or change your options. There is also a > button on your options page that will email your current password to > you. > > You may also have your password mailed to you automatically off of the > Web page noted above. > ============================================================= VIPܣôô http://vip.163.com ʮŮվѡˣ http://www.nease.net ٷְŮ - ѡ! http://love.163.com
RSS Feed