Network Working Group Nishit Vasavada
INTERNET DRAFT Amber Networks, Inc.
July 2001
ESP: Encapsulation Services Protocol
<draft-vasavada-pwe3-esp-00.txt>
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
This document describes "Encapsulation Services (ES)" Protocol (ESP)
- the signaling and real-time transport protocol, suitable for
emulation of layer 1 and layer 2 circuits (e.g. FR, TDM, ATM and
private leased lines) over IP transport networks.
ESP provides end-to-end signaling mechanism suitable to establish ESP
tunnels and sessions over the underlying tunneling protocol. We
currently use Layer Two Tunneling Protocol (L2TP) as defined in
[RFC2661]. Other tunneling protocol may be extended in future to
support ESP.
Each emulated layer 1/2 circuit is encapsulated in an ES session
inside an ES tunnel. The ES session parameters comply with the
parameters of the parent ES tunnel.
1. Introduction
With service providers moving towards all new IP backbone networks,
there is a need to carry access technologies (e.g., Frame Relay, ATM)
over the IP backbone network. Most of these legacy access methods are
based on Layer 2 technologies. However, IP traditionally being a
Layer 3 protocol, the challenge is to carry Layer 2 traffic over this
IP backbone.
Vasavada [Page 1]
INTERNET DRAFT July 2001
+----+ +------+ +===============+ +------+ +----+
|FRAD|-------|Edge |--| IP/MPLS |--|Edge |--------|FRAD|
+----+ |Router| | NETWORK | |Router| +----+
+------+ +===============+ +------+
Frame Relay Core IP backbone Frame Relay
<-----------> <--------------------> <------------>
<---------Encapsulation Service------>
One such example is shown in the above figure where two Frame Relay
Access Devices (FRADs) are connected through an IP backbone. Private
Frame Relay networks can also be attached to each other in similar
fashion. ESP running on the edge router carries the Frame relay link
across the IP/MPLS backbone network to the remote end in a
transparent way. ESP emulates the characteristics specific to Frame
Relay over the IP network and thus the FRADs at both ends think as if
they are connected either directly or through another Frame Relay
network. Such emulation method includes the signaling procedure
needed to establish the ES tunnels and sessions and then the control
protocol needed for the link quality monitoring and also the Frame
Relay specific control information propagation mechanisms (such as
LMI).
Today's enterprises also depend heavily over private lines, which
span across the globe. These private lines carry pure bit-streams,
which are never looked into by intermediate network nodes. Hence,
carrying these circuits across IP network requires a "Circuit
Emulation Service", in particular, "IP Circuit Emulation Service".
This is similar to ATM CES which is in use for several years now.
+----+ +------+ +===============+ +------+ +----+
|CPE |-------|Edge |--| IP/MPLS |--|Edge |--------|CPE |
+----+ |Router| | NETWORK | |Router| +----+
+------+ +===============+ +------+
Private Line Core IP backbone Private Line
<-----------> <--------------------> <------------>
<---------Encapsulation Service----->
In this case, Private Circuits are connected to the Edge Router. ES,
running on the edge Router performs "Circuit Emulation" over IP
network and carries the Private lines to remote end. In this case,
the emulation is more of a "Layer 1" circuit emulation. The control
protocol here needs to include mechanism to propagate layer 1 circuit
characteristics, such as Idle suppression and Alarm suppression.
Note that in case of Layer-1 private line emulation, the protocol
does not need both ends to have similar physical characteristics. On
one side, the customer can connect one DS1 of a channelized DS3 link,
whereas the customer on the other end can connect through a single
DS1 line. Yet information about idle-suppression and alarm status
etc. are semantically carried to the remote end.
1.1. Outline of rest of the document:
Section 2 defines the requirements of the protocol. Section 3 shows
a reference model using L2TP as the lower layer transport. Rest of
Vasavada [Page 2]
INTERNET DRAFT July 2001
the document is within the context of this reference model. Section
4 provides an overview of the protocol, while Section 5 describes the
protocol operation in detail. Section 6 talks about the ES control
message formats. Section 7 goes into issues specific to the access
link being encapsulated. Appendix A discusses the signaling with
L2TP.
2. Requirements of the Protocol
2.1. Connection Identifiers
One important inherent feature of traditional Layer 2 technologies
are their connection-oriented nature. But, IP being traditionally
connectionless protocol, there is a need to preserve the connection
identifiers of the Layer 2 technologies across the IP network. More
specifically, for Frame Relay, the (de)multiplexing based on Data
Link Connection Identifier (DLCI) must be preserved at the remote
end.
2.2. Alarms
Each access technology has some kind of "Alarm" built into the
specification of the technology. Such information must be preserved
and carried across the IP network for successful emulation of the
same. Frame Relay, for example uses "Link Management Interface (LMI)"
to carry such information. ES must have mechanism to propagate such
information between two ends.
2.3. Quality of Service
QoS issues are not addressed in this draft.
2.4. Other requirements
Another requirement for this service is the mechanism for privacy,
secrecy, encryption, authentication etc. The mechanism to emulate the
private lines must also provide facilities to realize the privacy of
user data being transported over the public IP network.
3. Reference Model
An emerging area in the evolution of IP network is the area of
"Tunneling Protocols". More specifically, RFC 2661 describes a
"Layer 2 Tunneling Protocol" (L2TP) as a means to tunnel PPP traffic
over various network clouds. It is proposed to use L2TP as a generic
tunneling mechanism and build an "Encapsulation Services" protocol to
meet the requirements described in Section 2.
A reference model which can be used for ESP is shown below. However,
it is possible to use ES over any other tunneling mechanism in an
IP/MPLS network. Future work will focus on these issues.
Vasavada [Page 3]
INTERNET DRAFT July 2001
+--------+--------+ +--------+--------+
| |ES | | ES | |
| +--------+ +--------+ |
| |L2TP | |L2TP | |
| Layer +--------+ +--------+ Layer |
| |UDP | |UDP | |
| 2 +--------+ +-----------+ +--------+ 2 |
| | | | | | | |
|Protocol| IP | | | | IP |Protocol|
| | | |IP NETWORK | | | |
+--------+--------+ +-----------+ +--------+--------+
^ ^ ^ ^ ^ ^
FR/TDM | | | | | |FR/TDM
----------+ +-----------+ +---------+ +------
Link Link
As shown in the diagram above, the access link is terminated and is
fed to ESP. An encapsulation scheme is defined (described later) for
this Layer 2 traffic. That, in turn, is encapsulated in L2TP/UDP/IP
stack and the resulting IP packet is sent across the IP network to
the remote end.
At the remote side, the ES/L2TP/UDP/IP encapsulation is removed and
the resulting packet is sent on the access link.
4. Encapsulation Services Protocol Overview
4.1. ES components
Encapsulation Services Protocol (ESP) consists of the following
components:
- ES tunnel signaling (only with lower layer - not on the wire)
- ES session signaling
- ES Data transport protocol
- ES Keep Alive Protocol
- ES Alarm propagation protocol
- ES Quality Report Protocol
4.2. Protocol Specification
ESP has two components - ES Tunnel and ES Session.
4.2.1. ES Session
An "ES Session" carries a single layer 1 or 2 connection through IP
network.
- In case of Frame Relay, a single DLCI corresponds to an ES session.
- In case of ATM, a single ATM VPI/VCI is carried in an ES session.
- In case of Layer 1 (TDM) circuits, an ES session carries the entire
circuit.
The primary objective of an ES session is to "emulate" the
characteristics of the circuit through the IP network. An ES session
performs the following:
Vasavada [Page 4]
INTERNET DRAFT July 2001
- Performs necessary signaling for connecting the two circuits at the
two ends of the network (with the help of underlying transport)
- Exchanges and negotiates the circuit-related traffic parameters
between the two end points
- Carries "Service Data Units" (SDUs) for the circuit
- Propagates the "Alarm" and "OAM" information through the IP network
to the remote end
- Maintains the connectivity of the circuit through the IP network by
appropriate "keep-alive" mechanism
- Monitors, prepares and generates "Quality Report" for the session
in IP network
4.2.2. ES Tunnel
An "ES Tunnel" is an aggregation of "ES sessions" which share the
following:
- All sessions are between the same pair of IP hosts (tunnel/session
end points)
- All sessions are for identical access technology (FR/ATM/TDM)
- All sessions require similar service level treatment in the IP
network
The following 4-tuple identifies an ES tunnel:
- IP address of tunnel's remote endpoint: This would typically be a
loop-back interface IP address of the remote host, but any other
value MAY be provisioned. For the purpose of accepting an ES
tunnel, this provisioned value is checked against the IP address of
incoming request.
- Access link type (FR/ATM/TDM/any other defined in future): This is
an ASCII string - current recognized values are "FR", "ATM" and
"CES" (for TDM circuits). Future work may involve standardizing
values for various access link types.
- Service attributes: Service attributes are represented by an ASCII
string mutually agreed on by the two ends in an "out-of-band" way
or administratively. This parameter maps to a specific set of
attributes of the service. This may include, but is not restricted
to the level of service, customer information, or any other
attributes which may differentiate the traffic in this tunnel from
that in any other tunnel. An example of this string is
"customer_a_gold".
- DS value: ES conveys this value to the lower layer transport.
Currently this applies to L2TP, in the context of [L2TPDS]. The
value is used both for the control packets (CCDS AVP as defined in
[L2TPDS]) and session packet (SDS AVP is defined in [L2TPDS]).
4.3. ES header format and encapsulation
A generic header format is proposed to facilitate data transport of
all kinds of Layer 2 protocols. The header is on the similar lines
of the RTP header with extensions/modifications for Encapsulation
Vasavada [Page 5]
INTERNET DRAFT July 2001
Services. There is a 16-bit IP like checksum for the ES header to
ensure correctness of sequence number and other header fields.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Reserved |P|M|I|A| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags:
- Ver: Version number, set to 1
- Reserved: Set to 0 on transmit, ignored on receipt
- P - for PCRC: Action on the payload CRC error. Drop the packet if
PCRC bit is 1, do not drop if the bit is 0. Latter case is used
for CES.
- H = Idle bit mask present (currently set to 0)
- I = Idle on/off (currently set to 0). If set to one, it indicates
that an AIS was received from local subscriber link, and the far
side should play idle pattern on the DS3 line.
- A = Alarm state on/off (currently set to 0)
- Packet sequence number: Incremented for every ES packet for a given
connection. Using sequence number is optional. If Sequence numbers
are not used, then this is set to 0. However, they are needed to
reorder packets received out of order. The sequence number starts
from and wraps to 1, not 0 (since 0 has special meaning).
- Length: Length of the payload
- Checksum: Used for the header and is 16 bit IP style checksum. If
the checksum is wrong, the packet will be dropped.
- CRC (32 bits) for the entire header and payload (to take care of
FR/ATM encapsulation). CRC is not used for ES control PDUs. ES
control PDUs compute a checksum over the ES control portion of the
PDU as described in individual control message descriptions.
5. ES Protocol Operation
Like most other protocols, ESP is split in two parts - Control Plane
and Data Plane.
5.1. ESP Control Plane
Setting up a tunnel (if needed), sessions within and the maintenance
messages are within the Control Plane. There is no ES level message
for setting up tunnel (see 5.1 for more on tunnel set-up) - lower
layer transport signaling is used for this purpose. All the ES
session messages have the following format:
12 byte ES Header + ES Control Message
ES header is defined in section 4.3. ES control messages are defined
in section 6.4. A 16 bit IP style checksum ensures integrity of
Vasavada [Page 6]
INTERNET DRAFT July 2001
control plane PDUs.
5.2. ESP Data Plane
Data plane carries the L1/L2 payload to the far end of the tunnel.
The ESP data plane PDUs have the following format:
12 byte ES Header + Encapsulated Payload [+ CRC]
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Reserved |P|M|I|A| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (only non-CES payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload is encapsulated and a CRC is added for FR and ATM cases.
The access link type specific discussion on payload encapsulation is
in Section 7.
The CRC is a 32 bit field at the end of the ES data PDU, and is
computed over the entire ES header and payload.
Rest of the document will mainly focus on the control plane.
5.3. ES Tunnel Signaling
5.3.1. ES Tunnel setup
When a network operator intends to carry certain Layer 1 or 2 traffic
to a certain remote IP host, the operator sets up an ES tunnel first.
An ES tunnel is a logical tunnel. It utilizes the tunnel set up by
the underlying transport protocol, e.g. an L2TP tunnel. No ES
control packets are exchanged for setting up an ES tunnel.
ES requests the underlying transport layer to setup a tunnel. The
distribution of provisioning and tunnel acceptance work is
implementation dependent. More information on this can be found in
Appendix A.
The Service Access Point between ES and L2TP is left to the
implementation. A good value to use would be the local tunnel ID
assigned by L2TP.
On receiving an indication from ES to set up a tunnel, the L2TP on
local side initiates the tunnel set-up. This follows the normal
Vasavada [Page 7]
INTERNET DRAFT July 2001
set-up procedure as outlined in [RFC2661] with following constraints:
- exchange ESP as a service type in the service capabilities AVP, as
defined in [L2TPST]. The M-bit is set for this AVP to
ensure the peer supports ESP.
- use the string consisting of access_type.service_attributes as the
hostname for the host name AVP
- DS value for the CCDS AVP as defined in [L2TPDS].
The remote side L2TP either processes the request at L2TP layer, or
passes on this request to ES providing the same <4-tuple> about the
originating side ES. This depends on the implementation as outlined
in Appendix A.
5.3.2. ES Tunnel Tear-down
This includes the following cases -
- Based on configured policies, ES determines that an incoming tunnel
should not be accepted
- User intends to tear down an existing tunnel.
Either way, ES notifies the underlying L2TP to release the tunnel.
While doing so, it specifies the SAP agreed up on when setting up the
tunnel (please see above). An appropriate L2TP error code SHOULD be
passed to L2TP, which L2TP can use while tearing down the tunnel.
5.4. ES Session Signaling
When user wants to connect a specific layer-1 or layer-2 circuit
(referred to as "access circuits" in the rest of the document) with a
remote circuit (layer-1 or layer-2 respectively), ES uses the session
signaling mechanisms for this purpose. An ES session is part of an
ES tunnel. For ES session to be established, a corresponding tunnel
MUST already exist.
The session terminates on the specific access circuit on the remote
side. User on one side requests ES to setup an ES session between the
two access circuits. ES specifies the local and remote side "access
circuit identifiers" to L2TP while requesting to set up a session in
the tunnel. These circuit identifiers depend on the specific Layer-1
or Layer-2 protocol that is being carried as listed below:
- Access port/line number and DLCI value for Frame Relay
- Access port/line number and VPI/VCI values for ATM
- Access port/line number for TDM circuits coming into the box
On the remote end, L2TP supplies the same set of identifiers to ES.
ES decides whether to accept or reject such an incoming call,
depending upon actual provisioning of the access circuit or some
other local policy.
If it wants to accept the call, it indicates so to L2TP. Otherwise,
it indicates to L2TP to reject the call and indicates the "Cause and
Diagnostic" code for the same.
Vasavada [Page 8]
INTERNET DRAFT July 2001
5.4.1. ES Session setup
The ESP session is transported by L2TP session PDUs. To set up an
ESP session, an L2TP session needs to be established first. L2TP
uses following attributes passed by ES while setting up the session.
5.4.1.1. Signaling parameter: End-Identifiers
The end identifiers are encoded in the End-Identifier AVP of L2TP
session set-up message. This field is a sequence of ASCII octets. ES
encodes this in a format (defined later) and supplies to L2TP. The ES
on the remote side decodes this to extract the appropriate access
circuit identifiers for the session.
The way the remote circuit ID is encoded depends on the access type.
For Frame Relay, both interface and DLCI information is needed. For
TDM circuits, only interface number is communicated.
5.4.1.2. Signaling parameter: Service Type
L2TP uses ES as the service type in the Service Type AVP while
setting up the session. If there is any problem in using ES as the
service type for the session, the session is torn down.
5.4.1.3 Signaling parameter: DS Value
DS value is same as the one used in tunnel set-up. L2TP uses it for
SDS AVP while setting up the session.
Once L2TP session is set up, ESP sets up a session.
5.4.1.2. Traffic parameter negotiation
After L2TP session gets established, ES on both sides exchanges the
access side traffic parameters with the other side. These parameters
are specific to the particular access link, carried in the session:
For Frame Relay circuits:
- Committed Information Rate (CIR)
- Committed Burst (Bc)
- Excess Burst (Be)
For TDM circuits:
- Packet Size
- Jitter
- Minimum queue depth
For ATM VCs: [TBD]
With the help of these signaling procedures, ES on both sides
performs necessary checks, such that ingress parameters on one side
matches the egress parameters on the remote side and vice-versa.
In case of a failure in such checks, ES drops the sessions with an
appropriate cause and diagnostics code.
Vasavada [Page 9]
INTERNET DRAFT July 2001
5.4.3. Session Tear-down
When user no longer needs the session, ES exchanges a "Terminate PDU"
with the remote peer and then brings down the underlying ES session.
5.4.4. Cause and diagnostic codes
Currently ES follows the well-established codes for L2TP. Future
work may involve setting up special codes for ES use.
5.5. Alarm Propagation
ES provides a mechanism to propagate access side "alarm information"
to remote side. This ensures that the user at the CPE sees a virtual
end-to-end layer-1/layer-2 link extending from its premise to the
remote premise.
The exact semantics of the alarm is access-technology dependent. The
specific alarms for Frame Relay, TDM circuits and ATM VCs are
described below:
5.5.1. Frame Relay
Local Management Interface (LMI) is used to perform link management
on LMI links. LMI has mechanisms to convey status of individual DLCI
(known as "A-bit status") on a frame relay link. ES terminates the
LMI protocol in the box and translates the information into ES
control PDU. The far side re-translates the ES control PDU back into
LMI message. Thus, both the ES end-points need to participate in LMI
protocol. Thus, the A-bit information gets propagated end-to-end
through the IP network in a transparent manner.
A particular implementation can choose the frequency of such
information exchange. It can be tied to the receipt of A-bit status
messages on one end on the link or can be performed in certain
periodic interval. Configuration or signaling of this periodic
interval will be covered in a future version.
Alarms can also be propagated in bulk so that multiple individual
alarms do not have to be transported across the IP network.
5.5.2. TDM circuits
The alarm information for a TDM circuit depends on the type of line
being emulated, e.g.: DS1 or DS3. Whenever a line (DS1 or DS3) goes
into alarm, ES sends a message to the remote ES specifying the
session corresponding to the line. The remote side ES plays the
appropriate alarm-bit-pattern for the appropriate interface.
5.5.3. ATM VCC
[TBD]
Vasavada [Page 10]
INTERNET DRAFT July 2001
5.6. Idle Suppression Protocol
When there is no traffic on a Layer-1 circuit, the line can be
carrying idle-pattern. In such a case, ES notifies the remote side
about the same. The remote device starts playing idle pattern on the
line.
5.7. Quality Report
ES provides a mechanism to monitor and provide feedback in terms of
"Link Quality Report" on a per-session basis. Such information is
collected/measured on the egress side of the session and is fed back
to the ingress side. Ingress side ES can take intelligent decisions
based on such information for building resiliency and robustness to
the service. It is optional on part of the egress equipment to
perform such measurement. It is also optional on part of the ingress
equipment to take any intelligent decision based on such information.
However, if egress equipment does measure and propagate the
information to the ingress side, then the ingress side equipment MUST
make it accessible to user.
The parameters included in such monitoring and measurements are:
- Packet Loss: It may not be possible to measure packet loss without
using the sequence numbers for each packet.
- Round Trip Delay (RTD): ES provides a special loop-back IP packet
which when implemented must be looped-back to the source with a
timestamp. This can be used to measure the round trip delay for a
packet on a session.
- Bandwidth: The instantaneous bandwidth observed on the egress side
can be measured for a Frame relay circuit.
- Jitter: The instantaneous jitter experienced on the egress side for
a TDM circuit emulation, can be fed back to the ingress side.
More work in this area will be done in near future.
5.8. Keep Alive Protocol
ES relies on L2TP's "Hello Protocol" to maintain the heart beat of
the tunnel.
6. ES Message formats
There are two classes of ES messages:
- One class contains three of the ES parameters that are signaled
using L2TP mechanisms: Service Capabilities, Service Type, DS and
End-Identifier
- The second class contains ES messages that are exchanged between
two ES peers as ES control packets (L2TP payload packets).
These messages are described below:
6.1. Service Capabilities and Service Type AVP (Signaled through L2TP)
The exchange of this information is beyond the scope of this
Vasavada [Page 11]
INTERNET DRAFT July 2001
document. Please refer to [L2TPES].
6.2. DS value (Signaled through L2TP)
The exchange of this information is beyond the scope of this
document. Please refer to [L2TPDS].
6.3. Remote end identifier (Signaled through L2TP AVP End-Identifier)
[L2TPES] defines the format of the End-Identifier AVP, which is used
to identify the local and remote access connection identifiers at
either end of the L2TP tunnel.
6.4. ES Control messages
The ES control messages are modeled in the same way as the PPP LCP
control packets. There are four classes of control messages:
- Session Configuration messages: These are used to exchange the
access side connection parameters.
- Session Terminate messages: These are exchanges to gracefully tear
down the ES session (before actually tearing down the corresponding
L2TP session).
- Access Alarm propagation messages: These messages are used to
propagate access side alarm status information. Alarms from
multiple sessions can be clubbed together and the message can be
sent on a tunnel basis.
- Link Quality Report messages: These are exchanged to report link
quality reports.
Every ES message is "request-response" based. For every message, the
remote ES peer sends back an acknowledgement to the sending ES peer.
For sending multiple messages on the same session, ES uses a sliding
window protocol with window size "1". The sender has to make the
transmission of every packet reliable by starting a timer and
awaiting an acknowledgement. Each message contains a "PDU-Identifier"
which must be sent back in the response message by the remote peer.
The sender must match the "PDU-Identifier" in the response message to
that in the last sent message to validate a response message.
A summary of ES control message is shown below:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code |PDU-Identifier | data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: The code field is one octet. It identifies the type of message
that is encoded. When an unknown code field is received, a
"Code Reject" message is generated.
The possible values of the "Code" field are:
Vasavada [Page 12]
INTERNET DRAFT July 2001
0x0001: Configure Request
0x0002: Configure Acknowledgement
0x0003: Configure NAK (Negative Acknowledgement)
0x0004: Configure Reject
0x0005: Reserved
0x0006: Reserved
0x0007: Reserved
0x0008: Reserved
0x0009: Quality Report Message
0x000a: Terminate Request
0x000b: Terminate Acknowledgement
0x000c: Bulk Alarm Message
0x000d: Bulk Alarm Acknowledgement
PDU-Identifier: It is a one octet field. It is used to identify a
response message with a request message sent out earlier. When a
message with invalid identifier is received, it is silently
discarded.
The PDU-Identifier must be changed whenever a new Configure Request
is generated and sent to the remote side and whenever a valid reply
has been received from the remote peer. When a Configure-Request is
retransmitted because of timeout, the PDU-Identifier value MAY be
changed. When responding to a request, the PDU-Identifier MUT match
the value contained in the request being responded to.
Data: The data field may contain fixed or variable number of octets,
depending upon the type of message encoded (indicated by "code"
field) as well as the access type (FR, TDM...). For the messages that
can contain variable number of octets, the length is obtained from
the header of the ES PDU (described in Section: 4.3).
Payload checksum: This is a 16 byte IP style checksum on the payload
beginning the "Code" field.
6.4.1. Configure Request (ConfReq)
The ES Configure Request message contains the access side connection
parameters. For Frame Relay, the parameters encoded are:
- CIR in "Kilo-Bits-per-second" (4 octets)
- Bc in "number of Bytes" (4 octets)
- Be in "number of Bytes" (4 octets)
The Configure Request message format for Frame Relay is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | CIR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIR | Bc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bc | Be |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Be | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasavada [Page 13]
INTERNET DRAFT July 2001
Code: 1 for ES Configure-Request
Identifier and FR related fields: As described above
For CES sessions, the parameters encoded are:
- Jitter in "10s of micro-seconds" (2 octets)
- Minimum Q-depth in "10s of micro-seconds" (2 octets)
- Packet Size
The Configure Request message format for CES sessions is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Queue Depth | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 1 for ES Configure-Request
Identifier and CES related fields: As described above
Upon receipt, the ES peer verifies that the requested parameters are
supported, and the proposed values are acceptable. If any parameter
is not acceptable, the parameter is included in the Configure Reject
message and returned to the sender of Configure Request message. If
a parameter is supported, but if the value is not acceptable, a
Configure NAK is sent to the sender of the Configure Request message.
The Configure NAK includes the parameters whose values proposed in
Configure Request is/are not acceptable, and offers an alternate
value for these parameters.
6.4.2. Configure Acknowledgement (ConfAck)
The receiver of a ConfReq message MUST send back a ConfAck to the
sender, if the parameters present in the message were agreeable with.
The format of the message is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 2 for Configure Acknowledgement
Identifier: As described above, this field is copied from the PDU
Identifier field in the Configure Request which this message is
acknowledging.
Data: This field is a byte by byte copy of the data portion of the
Vasavada [Page 14]
INTERNET DRAFT July 2001
Configure Request which this message is acknowledging.
Upon receipt, the recipient of ConfAck MUST find the ConfReq it
sent based on the PDU Identifier in the received ConfReq. If no such
ConfReq was sent, the ConfAck is silently discarded. If the ConfReq
was found, the data portion of the sent ConfReq and received ConfAck
are compared. If they are identical, ES session goes in up state.
However, if they are not identical, another ConfReq is sent to the
peer.
Data: Byte to byte copy of Configure-Request
6.4.3. Configure NAK (ConfNAK)
If the values present in the Configure Request message are not
agreeable with, a "Configure NAK (Negative Acknowledgement)" message
must be sent back to sender of ConfReq. The format of this message
is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 3 for ConfNAK
Identifier: As described above, this field is copied from the PDU
Identifier field in the Configure Request which this message is
NAKing.
Data: This field contains the parameters whose values in ConfReq were
not agreeable to the recipient. The sender of ConfNAK proposes new
values for these parameters and sends the message back to the sender
of ConfReq.
Upon receipt, the recipient of ConfNAK MUST check the proposed
values against its own configuration. If the values proposed in
ConfNAK are acceptable, a new Configure Request message SHOULD be
sent with all the parameters (including the ones which were not NAKed
by the other side). The values of the parameters NAKed will be the
values proposed in ConfNAK, or any other value per the configuration.
6.4.4. Configure Reject
If any/all parameter(s) present in the Configure Request message are
not acceptable to the receiving side based on the configuration, a
"Configure Reject" message back to sender of ConfReq. The format of
this message is shown below:
Vasavada [Page 15]
INTERNET DRAFT July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 4 for ConfRej
Identifier: As described above, this field is copied from the PDU
Identifier field in the Configure Request which this message is
NAKing.
Data: This field contains the parameters in ConfReq which are not
supported by the receiving side.
Upon receipt, the recipient of ConfRej MUST check the parameters
not supported by the other side. If the local configuration permits
carrying out the session without those parameters, a new Configure
Request MUST be sent without the parameters mentioned in Configure
Reject. If the local configuration does not permit setting up a
session without these parameters, the local side MUST send a
Terminate Request to tear down the session.
6.4.5. ES Quality Report
The need of the Quality Report has been described in section 5.7.
This area has been marked for future work.
6.4.6. ES Terminate Request
ESP uses this message to terminate an existing session. No
additional information is exchanged in this message. The format of
this message is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 10 for TermReq
6.4.7. ES Terminate Ack
ESP uses this message to acknowledge a terminate request received
from the peer. No additional information is exchanged in this
message. After sending this message, the sending side SHOULD clean
up the ESP session and inform the lower layer about the session
termination. Similarly, the receiving side SHOULD clean up the ESP
session and inform the lower layer about the session termination.
The format of this message is shown below:
Vasavada [Page 16]
INTERNET DRAFT July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 11 for TermAck
6.4.8. ES Bulk Alarm Message
This message is used to aggregate alarms on multiple ES sessions.
The format of this message is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Alarm Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID 1 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 12 for Bulk Alarm Message
Alarm Status: Two bytes - reflects the status of the alarm for the
sessions mentioned in this message
Session ID (one or more): The alarm status shows in the "Alarm
Status" field reflects the status of sessions whose IDs are mentioned
here.
6.4.9. ES Bulk Alarm Ack
This message is used to acknowledge Bulk Alarm Message. The format
of this message is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Alarm Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID 1 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Payload Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 13 for Bulk Alarm Response
Alarm Status: Two bytes - carries the same value as the one in Alarm
Status field of the Bulk Alarm Message being acknowledged
Session ID (one or more): These fields are copied from the Bulk Alarm
Message being acknowledged
Vasavada [Page 17]
INTERNET DRAFT July 2001
7. Layer 2 related issues
7.1. Layer 2 type independent issues
7.1.1. Out of order packets
Due to the inherent connection-less nature of IP networks, packets
may arrive out of order at the end of the ES tunnel. If packet
buffering and reordering is desired, sequence numbers SHOULD be
utilized in the ES header.
7.1.2. Packet integrity
A 16 bit checksum over the ES header, and a 32 bit CRC over the
entire ES header and payload ensures packet integrity and error
detection.
7.1.3. Connection Multiplexing
This is provided by carrying multiple ES sessions on top of L2TP
sessions in a single L2TP tunnel.
7.2. FR specific issues
7.2.1. CIR, Be and Bc
Although not needed for FR PVC, ES allows these parameters to be
signaled to the far side.
7.2.2. FECN
Both on the ingress and egress of the IP network, if there is any
congestion in the direction of flow of traffic, the FECN bit MAY be
set. If the FECN bit is already set, it SHOULD not be changed.
7.2.3. BECN
BECN bit is not changed in the current version. Future work may
involve setting it if necessary.
7.2.4. D/E
The D/E bit MAY be set at the ingress (when FR is encapsulated into
ES) of the network if the traffic does not conform to the negotiated
CIR/Be/Bc. If the D/E bit is already set, it SHOULD not be changed
at the ingress of the IP network. The D/E bit SHOULD not changed at
the egress of the IP network.
7.2.5. Encapsulation
The entire FR packet including the header is encapsulated. CRC16 is
not included.
Vasavada [Page 18]
INTERNET DRAFT July 2001
7.3. TDM circuits specific issues
TDM frames are encapsulated in entirety.
8. Security Considerations
All the underlying L2TP Security considerations remain, though no
'new' ones are introduced?
9. IANA Considerations
To be completed.
10. Intellectual Property Considerations
Amber Networks may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Amber Networks, Amber
intends to disclose those patents and license them on reasonable and
non-discriminatory terms.
11. Acknowledgments
Many thanks to Himansu Sahu, Stanley Fong, Harisankar Mallath, Ravi
Bhat, Imtiyaj Kaji and Chi Fai Ho for their help in reviewing this
draft.
12. References
[RFC2661] Townsley, et. al., "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, February 1999.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2119] Bradner S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[L2TPST]. McPherson D., Nanji S., "L2TP Service Type", Work in
Progress, April 2001.
[L2TPDS] Calhoun P., et. al., "L2TP Differentiated Services
Extension", draft-ietf-l2tpext-ds-03.txt, Work in Progress, March
2001.
[L2TPES] Vasavada N., "Encapsulation Services Protocol Service Type
for L2TP", draft-vasavada-l2tpext-es-svctype-00.txt, Work in
Progress, June 2001.
Vasavada [Page 19]
INTERNET DRAFT July 2001
13. Author's Address
Nishit Vasavada
Amber Networks, Inc.
48664 Milmont Drive
Fremont, CA 94538
Phone: +1 510.687.5200
Email: nishit@ambernetworks.com
Appendix A: ES Tunnel Signaling
The document only defines what identifies an ES tunnel. The
requirements are for a host, but the document does not restrict the
implementation as to which layer (ESP or the transport layer under
it - L2TP for now) the provisioning and signaling occurs, specially
since ES tunnel is a logical tunnel and no message exchange takes
place at ES level to set up a tunnel.
An implementation is required to do the following:
- ESP MUST provide the host name to L2TP. L2TP MUST use it for the
host name AVP and other implementation specific details related to
host name. L2TP MUST also use it to find other provisioned tunnel
parameters if they are provisioned at L2TP layer (please see
below).
An implementation is free to choose the following:
- Whether the tunnel is provisioned at the lower layer, or ES signals
the tunnel parameters to the lower layer. These parameters include
remote end IP address, host name and DS value to be used for tunnel
and sessions within the tunnel. If the host name is provisioned at
L2TP layer, it must conform to the ES needs of
"access_link_type.service_attributes" format - e.g.
"FR.customer_a_gold".
- Whether the tunnel is accepted at L2TP layer, or ES layer. If it
is accepted at ES layer, L2TP MUST confirm with ES whether the
incoming tunnel request can be accepted. If the tunnel acceptance
processing is done at ESP layer, and if ESP decides to not accept
the request, ESP MUST pass to L2TP an appropriate error/cause code
which L2TP can use to send out a StopCCN.
- The source IP address in the received packet used MUST match the
remote endpoint address as provisioned.
Vasavada [Page 20]