< draft-pate-pwe3-framework-00.txt   draft-pate-pwe3-framework-01.txt >
Internet Draft Prayson Pate Internet Draft Prayson Pate
Document: draft-pate-pwe3-framework-00.txt Overture Networks Document: draft-pate-pwe3-framework-01.txt Overture Networks
Expires: November 18, 2001 XiPeng Xiao Expires: January 13, 2002 XiPeng Xiao
Photuris Inc. Photuris Inc.
Tricci So Tricci So
Caspian Networks Caspian Networks
Craig White Craig White Kireeti Kompella
Level 3 Communications, LLC. Level 3 Communications, LLC. Juniper Networks, Inc.
Kireeti Kompella Andrew G. Malis Thomas K. Johnson
Juniper Networks, Inc. Vivace Networks Litchfield Communications
Framework for Framework for
Pseudo Wire Emulation Edge-to-Edge (PWE3) Pseudo Wire Emulation Edge-to-Edge (PWE3)
draft-pate-pwe3-framework-00.txt draft-pate-pwe3-framework-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line ? skipping to change at page 2, line ?
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes a framework for Pseudo Wires Emulation Edge- This document describes a framework for Pseudo Wires Emulation Edge-
to-Edge (PWE3). It discusses the emulation of circuits (such as T1, to-Edge (PWE3). It discusses the emulation of circuits (such as T1,
E1, T3 and E3) and services (such as ATM and Frame relay) over packet E1, T3, E3 and SONET/SDH) and services (such as ATM and Frame Relay)
networks using IP, L2TP or MPLS for transport. It presents an over packet switched networks (PSNs) using IP, L2TP or MPLS. It
architectural framework for pseudo wires, defines terminology, presents an architectural framework for pseudo wires (PWs), defines
specifies the various protocol elements and their functions, terminology, specifies the various protocol elements and their
overviews some of the services that will be supported and discusses functions, overviews some of the services that will be supported and
how pseudo wires fit into the broader context of protocols. discusses how PWs fit into the broader context of protocols.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Table of Contents Table of Contents
1 Introduction ................................................. 3
1 Introduction ................................................. 5 2 Background and Motivation .................................... 5
1.1 What Are Pseudo Wires? .................................... 5 3 Architecture of Pseudo Wires ................................. 8
1.1.1 Definition ............................................... 5 4 Layer 1 (Circuit) Applications ............................... 15
1.1.2 Functions ................................................ 5 5 Layer 2 (Packet/Cell) Applications ........................... 25
1.2 Goals of This Document ..................................... 6 6 PW Maintenance ............................................... 36
1.3 Non-Goals .................................................. 6 7 Packet Switched Networks ..................................... 40
2 Background and Motivation .................................... 7 8 Acknowledgments .............................................. 43
2.1 Current Network Architecture ............................... 7 9 References ................................................... 43
2.1.1 Multiple Networks ........................................ 7 10 Security Considerations ..................................... 45
2.1.2 Convergence Today ........................................ 8 11 Authors' Addresses .......................................... 46
2.2 The Emerging Converged Network ............................. 8 12 Full Copyright Section ...................................... 47
2.3 Transition to the New Network .............................. 9
3 Architecture of Pseudo Wires ................................. 10
3.1 Reference Model ............................................ 10
3.2 Terminology ................................................ 10
3.3 Architecture Assumptions ................................... 11
3.4 Comparison of Relevant Applications ........................ 13
4 Layer 1 (Circuit) Applications ............................... 14
4.1 Reference Model ............................................ 14
4.2 Operational Considerations ................................. 15
4.2.1 Transparency ............................................. 15
4.2.2 Framed Versus Unframed Mode For TDM Circuits ............. 15
4.2.3 Fractional T1/E1 ......................................... 16
4.2.4 Loopbacks ................................................ 16
4.2.5 Performance Processing ................................... 16
4.2.6 LOS/LOF/AIS/RAI .......................................... 16
4.2.7 SONET/SDH STS Unequipped ................................. 17
4.3 Encapsulations ............................................. 18
4.3.1 Criteria ................................................. 18
4.3.2 SONET Encapsulation ...................................... 18
4.3.2.1 SPE .................................................... 18
4.3.2.2 Section/Line ........................................... 18
4.3.2.3 VT ..................................................... 19
4.3.3 ATM AAL1 Encapsulation ................................... 20
5 Layer 2 (Packet/Cell) Applications ........................... 21
5.1 Layer 2 PW Reference Model ................................. 21
5.2 Ethernet ................................................... 22
5.2.1 Reference Model Scope .................................... 22
5.2.2 Operational Considerations ............................... 22
5.2.2.1 Operational Modes ...................................... 22
5.2.2.2 Quality Of Service Support Considerations .............. 23
5.3 Frame Relay ................................................ 24
5.3.1 Reference Model .......................................... 24
5.3.2 Operational Considerations ............................... 26
5.3.2.1 Frame Sequence ......................................... 26
5.3.2.2 Frame Size ............................................. 26
5.3.2.3 End-to-end Transport Characteristics ................... 26
5.3.2.4 Connection Management and Congestion Control ........... 26
5.3.2.5 Link Management Support ................................ 26
5.3.2.6 DLCI Association ....................................... 27
5.3.2.7 Multiplexing VCs over PWs .............................. 27
5.3.2.8 Signaling Transparency ................................. 27
5.3.2.9 Soft PVC Support ....................................... 28
5.4 ATM ........................................................ 29
5.4.1 Reference Model .......................................... 29
5.4.2 Operational Considerations ............................... 29
5.4.2.1 Cell Sequence .......................................... 29
5.4.2.2 End-to-end Transport Characteristics ................... 29
5.4.2.3 ATM SLA ................................................ 29
5.4.2.4 Connection Management and Congestion Control ........... 29
5.4.2.5 OAM and Link Management Support ........................ 30
5.4.2.6 VC Associations ........................................ 30
5.4.2.7 Multiplexing ATM VCs over PWs .......................... 31
5.4.2.8 ATM Signaling Transparency ............................. 31
5.4.2.9 Soft PVC Support ....................................... 31
5.4.2.10 Segmentation and Reassembly (SAR) ..................... 31
6 Timing ....................................................... 32
6.1 Reference Model ............................................ 32
6.2 Recreating the Timing ...................................... 33
6.3 External Timing ............................................ 33
6.4 SONET Pointer Justification ................................ 33
6.5 Differential (SRTS) ........................................ 34
6.6 Adaptive Timing ............................................ 35
6.7 RTP ........................................................ 36
6.7.1 RTP Timestamps ........................................... 36
6.7.2 Analysis of Clock Drift .................................. 36
6.7.3 RTCP/NTP as a Solution ................................... 37
6.8 Summary of Timing Recovery Methods ......................... 37
7 Integrity .................................................... 38
7.1 Validation ................................................. 38
7.2 Sequencing ................................................. 38
8 Management ................................................... 38
8.1 Session Multiplexing ....................................... 38
8.2 Signaling .................................................. 38
8.3 Security ................................................... 38
8.4 Encapsulation Control ...................................... 38
8.5 Statistics ................................................. 38
8.6 Administrative Status ...................................... 39
8.7 Operational Status ......................................... 39
9 Transport Protocols .......................................... 39
9.1 IP ......................................................... 39
9.2 L2TP ....................................................... 39
9.3 MPLS ....................................................... 39
9.4 Common Infrastructure ...................................... 39
10 Acknowledgments ............................................. 39
11 References .................................................. 40
11.1 IETF RFCs ................................................. 40
11.2 IETF Drafts ............................................... 40
11.3 ATM Forum ................................................. 40
11.4 Frame Relay Forum ......................................... 40
11.5 ITU ....................................................... 41
11.6 IEEE ...................................................... 41
11.7 ANSI ...................................................... 42
11.8 Telcordia ................................................. 42
12 Security Considerations ..................................... 42
13 Authors' Addresses .......................................... 42
14 Full Copyright Section ...................................... 43
1. Introduction 1. Introduction
This document describes a framework for Pseudo Wires Emulation Edge- This document describes a framework for Pseudo Wires Emulation Edge-
to-Edge (PWE3). It discusses the emulation of circuits (such as T1, to-Edge (PWE3). It discusses the emulation of circuits (such as T1,
E1, T3 and E3) and services (such as ATM and Frame relay) over packet E1, T3, E3 and SONET/SDH) and services (such as ATM and Frame Relay)
networks using IP, L2TP or MPLS for transport. It presents an over packet switched networks (PSNs) using IP, L2TP or MPLS. It
architectural framework for pseudo wires, defines terminology, presents an architectural framework for pseudo wires (PWs), defines
specifies the various protocol elements and their functions, terminology, specifies the various protocol elements and their
overviews the services supported and discusses how pseudo wires fit functions, overviews the services supported and discusses how PWs fit
into the broader context of protocols. into the broader context of protocols.
1.1. What Are Pseudo Wires? 1.1. What Are Pseudo Wires?
1.1.1. Definition 1.1.1. Definition
A pseudo wire (PW) is a mechanism that emulates the essential PWE3 is a mechanism that emulates the essential attributes of a
attributes of a service (such as a T1 leased line or Frame Relay) service (such as a T1 leased line or Frame Relay) over a PSN. The
over a packet network. The required functions of PWs include required functions of PWs include encapsulating service-specific bit-
encapsulating service-specific bit-streams or PDUs arriving at an streams or PDUs arriving at an ingress port, and carrying them across
ingress port, and carrying them across a path or tunnel, managing a path or tunnel, managing their timing and order, and any other
their timing and order, and any other operations required to emulate operations required to emulate the behavior and characteristics of
the behavior and characteristics of the service as faithfully as the service as faithfully as possible.
possible.
From the customer perspective, the PW is perceived as an unshared From the customer perspective, the PW is perceived as an unshared
link or circuit of the chosen service. However, there may be link or circuit of the chosen service. However, there may be
deficiencies that impede some applications from being carried on a deficiencies that impede some applications from being carried on a
PW. These limitations should be fully described in the appropriate PW. These limitations should be fully described in the appropriate
service-specific Applicability Statements (ASes). service-specific Applicability Statements (ASes).
1.1.2. Functions 1.1.2. Functions
PWs provide the following functions in order to emulate the behavior PWs provide the following functions in order to emulate the behavior
and characteristics of the desired service. and characteristics of the desired service.
- Encapsulation of service-specific PDUs or circuit data arriving at - Encapsulation of service-specific PDUs or circuit data arriving at
an ingress port (logical or physical). an ingress port (logical or physical).
- Transporting the encapsulated data across a tunnel. - Carrying the encapsulated data across a tunnel.
- Managing the signaling, timing, order or other aspects of the - Managing the signaling, timing, order or other aspects of the
service at the boundaries of the PW. service at the boundaries of the PW.
- Service-specific status signaling and alarm management.
ASes for each service will describe any shortfalls of the emulation's ASes for each service will describe any shortfalls of the emulation's
faithfulness. faithfulness.
1.2. Goals of This Document 1.2. Goals of This Document
- Description of the motivation for creating PWs, and some background - Description of the motivation for creating PWs, and some background
on how they may be deployed. on how they may be deployed.
- Description of an architecture and terminology for PWs. - Description of an architecture and terminology for PWs.
- Description of the relevant services that will be supported by PWs, - Description of the relevant services that will be supported by PWs,
including any relevant service-specific considerations. including any relevant service-specific considerations.
- Description of methods to ensure in-order final PDU delivery, - Description of methods to ensure in-order final PDU delivery,
- Description of methods to perform clock recovery, as needed or - Description of methods to perform clock recovery, as needed or
appropriate. appropriate.
- Description of methods to perform edge-to-edge/inband signaling - Description of methods to perform edge-to-edge/inband signaling
functions across the transport network as needed or appropriate. functions across the PSN, as needed or appropriate.
- Description of the statistics and other network management - Description of the statistics and other network management
information needed for tunnel operation and management. information needed for tunnel operation and management.
- Description of the security mechanisms to be used to protect the - Description of the security mechanisms to be used to protect the
control of the PW technology. The protection of the encapsulated control of the PW technology. The protection of the encapsulated
content (e.g., payload encryption) of the PW is outside of scope. content (e.g., payload encryption) of the PW is outside of scope.
- Description of a mechanism to exchange encapsulation control - Description of a mechanism to exchange encapsulation control
information at an administrative boundary of the transport network, information at an administrative boundary of the PSN, including
including security methods. security methods.
- Whenever possible, relevant requirements from existing IETF - Whenever possible, relevant requirements from existing IETF
documents and other sources will be incorporated by reference. documents and other sources will be incorporated by reference.
1.3. Non-Goals 1.3. Non-Goals
The following are out of scope: The following are out of scope:
- The protection of the encapsulated content of the PW. - The protection of the encapsulated content of the PW.
- Any multicast service not native to the emulated medium. Thus, - Any multicast service not native to the emulated medium. Thus,
Ethernet transmission to a "multicast" IEEE-48 address is in scope, Ethernet transmission to a "multicast" IEEE-48 address is in scope,
while multicast services like MARS that are implemented on top of while multicast services like MARS that are implemented on top of
the medium are out of scope. the medium are out of scope.
- Methods to signal the underlying network - Methods to signal the underlying PSN.
2. Background and Motivation 2. Background and Motivation
Many of today's service providers are struggling with the dilemma of Many of today's service providers are struggling with the dilemma of
moving to an optical network based on IP and/or MPLS. How do they moving to an optical network based on IP and/or MPLS. How do they
realize the capital and operational benefits of a new packet-based realize the capital and operational benefits of a new packet-based
optical infrastructure, while leveraging the existing base of SONET optical infrastructure, while leveraging the existing base of SONET
(Synchronous Optical Network) gear, and while also protecting the (Synchronous Optical Network) gear, and while also protecting the
large revenue stream associated with this equipment? How do they large revenue stream associated with this equipment? How do they
move from mature Frame Relay or ATM networks, while still being able move from mature Frame Relay or ATM networks, while still being able
to provide these lucrative services? One possibility is the to provide these lucrative services? One possibility is the
emulation of circuits or services, currently referred to as "pseudo emulation of circuits or services via PWs. Circuit emulation over
wires" in the IETF. Circuit emulation over ATM and interworking of ATM and interworking of Frame Relay and ATM have already been
Frame Relay and ATM have already been standardized. Emulation allows standardized. Emulation allows existing circuits and/or services to
the transport of existing circuits and/or services across the new be carried across the new infrastructure, and thus enables the
infrastructure, and thus enables the interworking of disparate interworking of disparate networks. [ATMCES] provides some insight
networks. [ATMCES] provides some insight into the requirements for into the requirements for such a service:
such a service:
There is a user demand for carrying certain types of There is a user demand for carrying certain types of
constant bit rate (CBR) or "circuit" traffic over constant bit rate (CBR) or "circuit" traffic over
Asynchronous Transfer Mode (ATM) networks. As ATM is Asynchronous Transfer Mode (ATM) networks. As ATM is
essentially a packet- rather than circuit-oriented essentially a packet- rather than circuit-oriented
transmission technology, it must emulate circuit transmission technology, it must emulate circuit
characteristics in order to provide good support for CBR characteristics in order to provide good support for CBR
traffic. traffic.
A critical attribute of a Circuit Emulation Service (CES) A critical attribute of a Circuit Emulation Service (CES)
skipping to change at page 7, line 51 skipping to change at page 5, line 51
and video services. It is transparent to both protocols and and video services. It is transparent to both protocols and
signaling, irrespective of whether they are standards based signaling, irrespective of whether they are standards based
or proprietary with full timing support and the capability or proprietary with full timing support and the capability
of maintaining the integrity of framed and unframed DS1 of maintaining the integrity of framed and unframed DS1
formats. formats.
2.1. Current Network Architecture 2.1. Current Network Architecture
2.1.1. Multiple Networks 2.1.1. Multiple Networks
The current "network" for any given service provider delivering For any given service provider delivering multiple services, the
multiple services usually consists of parallel networks. Each of current "network" usually consists of parallel or "overlay" networks.
these networks implements a specific service, such as voice, Frame Each of these networks implements a specific service, such as voice,
Relay, internet access, etc. This is quite expensive, both in terms Frame Relay, Internet access, etc. This is quite expensive, both in
of capital expense as well as in operational costs. Furthermore, terms of capital expense as well as in operational costs.
multiple networks complicates planning. Service providers wind up Furthermore, the presence of multiple networks complicates planning.
asking themselves these questions:
- Which network do I build out? Service providers wind up asking themselves these questions:
- Which of my networks do I build out?
- How many fibers do I need for each network? - How many fibers do I need for each network?
- How do I efficiently manage multiple networks? - How do I efficiently manage multiple networks?
2.1.2. Convergence Today 2.1.2. Convergence Today
There are some examples of convergence in today's network: There are some examples of convergence in today's network:
- Frame Relay is frequently carried over ATM networks using [FRF.5] - Frame Relay is frequently carried over ATM networks using [FRF.5]
interworking. interworking.
- T1, E1 and T3 circuits are sometimes carried over ATM networks - T1, E1 and T3 circuits are sometimes carried over ATM networks
using [ATMCES]. using [ATMCES].
- Voice is carried over Frame Relay and IP networks. - Voice is carried over ATM (using AAL2), Frame Relay (using FRF.11
VoFR), IP (using VoIP) and MPLS (using VoMPLS) networks.
Deployment of these examples range from limited (ATM CES) to fairly Deployment of these examples range from limited (ATM CES) to fairly
common (FRF.5 interworking) to widespread (VoIP). common (FRF.5 interworking) to rapidly growing (VoIP).
2.2. The Emerging Converged Network 2.2. The Emerging Converged Network
Many service providers are finding that the new IP-based and MPLS- Many service providers are finding that the new IP-based and MPLS-
based switching systems are much less costly to acquire, deploy and based switching systems are much less costly to acquire, deploy and
maintain than the systems that they replace. The new systems take maintain than the systems that they replace. The new systems take
advantage of advances in technology in these ways: advantage of advances in technology in these ways:
- The newer systems leverage mass production of ASICs and optical - The newer systems leverage mass production of ASICs and optical
interfaces to reduce capital expense. interfaces to reduce capital expense.
- The bulk of the traffic in the network today originates from packet - The bulk of the traffic in the network today originates from packet
sources. Packet switches can economically switch and transport sources. Packet switches can economically switch and deliver this
this traffic natively. traffic natively.
- Variable-length switches have lower system costs than ATM due to - Variable-length switches have lower system costs than ATM due to
simpler switching mechanisms as well as elimination of segmentation simpler switching mechanisms as well as elimination of segmentation
and reassembly (SAR) at the edges of the network. and reassembly (SAR) at the edges of the network.
- Deployment of services is simpler due to the connectionless nature - Deployment of services is simpler due to the connectionless nature
of IP services or the rapid provisioning of MPLS applications. of IP services or the rapid provisioning of MPLS applications.
2.3. Transition to the New Network 2.3. Transition to a IP-Optimized Converged Network
The emergence of a converged network solves many of the problems The greatest assets for many service providers are the physical
faced by service providers, but the old networks and services don't communications links that they own. The time and costs associated
just go away. Use of PWs can help facilitate this transition with with acquiring the necessary rights of way, getting the required
these benefits. governmental approvals, and physically installing the cabling over a
variety of terrains and obstacles represents a significant asset that
is difficult to replace. Their greatest on-going costs are the
operational expenses associated with maintaining and operating their
networks. In order to maximize the return on their assets and
minimize their operating costs, service providers often look to
consolidate the delivery of multiple service types onto a single
networking technology.
- Leverage the low capital and operational expenses of packet The first generation converged network is based on TDM (time-division
networks. multiplexing) technology. Voice, video, and data traffic has been
carried successfully across TDM/DACS-based networks for decades. TDM
technology has some significant drawbacks as a converged networking
technology. Operational costs for TDM networks remain relatively
high because the provisioning of end-to-end TDM circuits is typically
a tedious and labor-intensive task. In addition, TDM switching does
not make the best use of the communications links. This is because
fixed assignment of timeslots does not allow for the statistical
multiplexing of bursty data traffic (i.e. temporarily unused
bandwidth on one timeslot cannot be dynamically re-allocated to
another service).
- Simple provisioning. The second generation of converged network is based on ATM
technology. Today many service providers convert voice, video, and
data traffic into fixed-length cells for carriage across ATM-based
networks. ATM improves upon TDM technology by providing the ability
to statistically multiplex different types of traffic onto
communications links. In addition, ATM SPVC technology is often used
to automatically provision end-to-end services, providing an
additional advantage over traditional TDM networks. However, ATM has
several significant drawbacks. One of the most frequently cited
problems with ATM is the so-called cell-tax, which refers to the 5
bytes out of 53 used as an ATM cell header. Another significant
problem with ATM is the AAL5 SAR, which becomes extremely difficult
to implement above 1 Gbps. There are also issues with the long-term
scalability of ATM, especially as a switching layer beneath IP.
- Provide a transition path to a converged network. As IP traffic takes up a larger and larger portion of the available
network bandwidth, it becomes increasingly useful to optimize public
networks for the Internet Protocol. However, many service providers
are confronting several obstacles in engineering IP-optimized
networks. Although Internet traffic is the fastest growing traffic
segment, it does not generate the highest revenue per bit. For
example, Frame Relay traffic currently generates a higher revenue per
bit than do native IP services. Private line TDM services still
generate even more revenue per bit than does Frame Relay. In
addition, there is a tremendous amount of legacy equipment deployed
within public networks that does not communicate using the Internet
Protocol. Service providers continue to utilize non-IP equipment to
deploy a variety of services, and see a need to interconnect this
legacy equipment over their IP-optimized core networks.
Editor's Note: this section needs more work. To maximize the return on their assets and minimize their operational
costs, many service providers are looking to consolidate the delivery
of multiple service offerings and traffic types onto a single IP-
optimized network.
In order to create this next-generation converged network, standard
methods must be developed to emulate existing telecommunications
formats such as Ethernet, Frame Relay, ATM, and TDM over IP-optimized
core networks. This document describes a framework accomplishing
this goal.
3. Architecture of Pseudo Wires 3. Architecture of Pseudo Wires
3.1. Reference Model 3.1. Terminology
Figure 1 below shows the reference model for PWs. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. Below are
the definitions for the terms used throughout the document.
|<--------- pseudo wire -------->| Packet Switched Network
| | A Packet Switched Network (PSN) is a network
| +------+ | using IP, MPLS or L2TP as the unit of
service |PW-PDU| -> service switching.
+-----+ access +------+ +------+ +------+ access +-----+
| SE1 |---------| PWE1 |..................| PWE2 |---------| SE2 |
+-----+ +------+ +------+ +-----+
PW endpoint 1 PW endpoint 2
| |
|<---------------- emulated service ---------------->|
service service Pseudo Wire Emulation Edge to Edge
endpoint 1 endpoint 2 Pseudo Wire Emulation Edge to Edge (PWE3) is a
mechanism that emulates the essential
attributes of a service (such as a T1 leased
line or Frame Relay) over a PSN.
Figure 1: PW Reference Model Customer Edge A Customer Edge (CE) is a device where one end
of an emulated service originates and
terminates. The CE is not aware that it is
using an emulated service rather than a "real"
service.
As shown, the PW provides an emulated service between the service Provider Edge A Provider Edge (PE) is a device that provides
endpoints. Any bits or packets presented at the service access are PWE3 to a CE.
encapsulated in a PW PDU and carried across the underlying network.
The PW endpoints (PWE) perform the encapsulation, decapsulation,
order management, timing and any other functions required by the
service. The underlying transport network is not involved in any of
these service-specific operations.
3.2. Terminology Pseudo Wire A Pseudo Wire (PW) is a connection between two
PEs carried over a PSN. The PE provides the
adaptation between the CE and the PW.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", PW End Service A Pseudo Wire End Service (PWES) is the
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this interface between a PE and a CE. This can be a
document are to be interpreted as described in RFC 2119. Below are physical interface like a T1 or Ethernet, or a
the definitions for the terms used throughout the document. virtual interface like a VC or VLAN.
Pseudo Wire The Pseudo Wire (PW) is a mechanism that Pseudo Wire PDU A Pseudo Wire PDU is a PDU sent on the PW that
emulates the essential attributes of a contains all of the data and control
service, providing this emulation over a information necessary to provide the desired
packet network. service.
Pseudo Wire Domain A PW Domain (PWD) is a collection of PSN Tunnel A PSN Tunnel is a tunnel inside which multiple
instances of PWs that are within the scope of PWs can be nested so that they are transparent
a single homogenous administrative domain to core network devices.
(e.g. PW over MPLS network or PW over IP
network etc.).
Pseudo Wire Endpoint The PW Endpoint (PWE) is a device that Pseudo Wire Domain A PW Domain (PWD) is a collection of instances
provides the adaptation between the end of PWs that are within the scope of a single
service and the PW. homogenous administrative domain (e.g. PW over
MPLS network or PW over IP network etc.).
Pseudo Wire PDU The PW-PDU is a PDU sent on the PW that Path-oriented PW A Path-oriented PW is a PW for which the
contains all of the data and control network devices of the underlying PSN must
information necessary to provide the desired maintain state information.
service.
Service Endpoint The Service Endpoint (SE) is the point of Non-path-oriented PW A Non-path-oriented PW is a PW for which the
termination for the emulated service. network devices of the underlying PSN need not
maintain state information.
Network Interworking Network Interworking means that the ingress Interworking Interworking is used to express interactions
and egress of the PW interfaces are identical between networks, between end systems, or
(e.g. ATM-to-ATM, Frame Relay-to-Frame Relay between parts thereof, with the aim of
etc.). The interworking function (IWF) at providing a functional entity capable of
the edge of the PW performs the service supporting an end-to-end communication. The
mapping (e.g. ATM Cell Loss priority (CLP) interactions required to provide a functional
maps to EXP field in MPLS header) on the entity rely on functions and on the means to
service data unit (SDU) (e.g. ATM cell) to select these functions.
ensure the service transparency while
transporting the SDU data transparently
across the PWD.
Service Interworking Service Interworking means that the ingress Interworking Function An Interworking Function (IWF) is a functional
and egress of the PW interfaces are different entity that facilitates interworking between
(e.g. ATM-to-Frame Relay). The interworking two dissimilar networks (e.g., ATM & MPLS, ATM
function at the ingress edge of the network & L2TP, etc.). A PE performs the IWF function.
terminates the SDU transport (e.g. ATM AAL5
PDU transport)and performs service mapping
between the ingress SDU and the pseudo-wire
PDU (e.g. ATM CLP to MPLS EXP) while it is
converting the incoming SDU into the PW SDU
(e.g. transcoding ATM AAL5 PDU into MPLS PDU)
and transports converted PDU across the PWD.
The same operation may be repeated in the
reverse order at the egress PW if the
outgoing interface does not have the same SDU
type as the PW.
Applicability Statement Each PW service will have an Applicability Service Interworking In Service Interworking, the IWF (Interworking
Statement (AS) that describes the particulars Function) between two dissimilar protocols
of PWs for that service, as well as the (e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP,
degree of faithfulness to that service. ATM & L2TP, etc.) terminates the protocol used
in one network and translates (i.e. maps) its
Protocol Control Information (PCI) to the PCI
of the protocol used in other network for User,
Control and Management Plane functions to the
extent possible. In general, since not all
functions may be supported in one or other of
the networks, the translation of PCI may be
partial or non-existent. However, this should
not result in any loss of user data since the
payload is not affected by PCI conversion at
the service interworking IWF.
Network Interworking In Network Interworking, the PCI (Protocol
Control Information) of the protocol and the
payload information used in two similar
networks are transferred transparently by an
IWF of the PE across the PSN. Typically the
IWF of the PE encapsulates the information
which is transmitted by means of an adaptation
function and transfers it transparently to the
other network.
Applicability Statement
Each PW service will have an Applicability
Statement (AS) that describes the particulars
of PWs for that service, as well as the degree
of faithfulness to that service.
Outbound The traffic direction where information from a
CE is adapted to a PW, and PW-PDUs are sent
into the PSN.
Inbound The traffic direction where PW-PDUs are
received on a PW from the PSN, re-converted
back in the emulated service, and sent out to a
CE.
CE Signaling CE (end-to-end) Signaling refers to messages
sent and received by the CEs. It may be
desirable or even necessary for the PE to
participate in or monitor this signaling in
order to effectively emulate the service.
PE/PW Signaling PE/PW Signaling is signaling used by the PEs to
set up and tear down the PW. It may be coupled
with CE signaling in order to effectively
manage the PW.
PSN Tunnel Signaling PSN Tunnel Signaling is used to set up,
maintain and remove the underlying PSN tunnel.
An example would be LDP in MPLS for maintaining
LSPs. This type of signaling is not within the
scope of PWE3.
<Editor's Note: The following figure is temporary. It is intended to
facilitate discussion of the preceding set of terms versus those used
in [MARTINI].>
[MARTINI] This Draft
----------------------------------------
MPLS Network PSN (includes MPLS)
Tunnel LSP PSN Tunnel
VC LSP PW
Edge LSR, R1, R2 PE
Figure 1: Comparison of Terms
3.2. Reference Models
3.2.1. Network Reference Model
Figure 2 below shows the network reference model for PWs.
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
PW V V V V PW
End Service+----+ +----+ End Service
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ | | |==================| | | +-----+
^ +----+ +----+ | ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 2: PWE3 Network Reference Model
As shown, the PW provides an emulated service between the customer
edges (CEs). Any bits or packets presented at the PW End Service
(PWES) are encapsulated in a PW-PDU and carried across the underlying
network. The PEs perform the encapsulation, decapsulation, order
management, timing and any other functions required by the service.
In some cases the PWES can be treated as a virtual interfaces into a
further processing (like switching or bridging) of the original
service before the physical connection to the CE. Examples include
Ethernet bridging, SONET cross-connect, translation of locally-
significant identifiers such as VCI/VPI, etc. to other service type,
etc.
The underlying PSN is not involved in any of these service-specific
operations.
3.2.2. Signaling Reference Model
Figure 3 below shows the signaling reference model for PWs.
|<------- CE (end-to-end) Signaling ------>|
| |
| |
| |<----- PW/PE Signaling ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| | | Signaling | | |
| V V V V |
v +-----+ +-----+ v
+-----+ | PE1 |==================| PE2 | +-----+
| |-----|.............PW1..............|-----| |
| CE1 | | | | | | CE2 |
| |-----|.............PW2..............|-----| |
+-----+ | |==================| | +-----+
^ +-----+ +-----+ ^
| Provider Edge 1 Provider Edge 2 |
| |
|<----------- Emulated Service ----------->|
Customer Customer
Edge 1 Edge 2
Figure 3: PWE3 Signaling Reference Model
- The CE (end-to-end) signaling is between the CEs. This signaling
includes Frame Relay PVC status signaling, ATM SVC signaling, etc.
- The PW/PE signaling is used between the PEs to set up and tear down
PWs, including any required coordination of parameters between the
two ends.
- The PSN Tunnel signaling controls the underlying PSN. An example
would be LDP in MPLS for maintaining LSPs. This type of signaling
is not within the scope of PWE3.
3.2.3. Protocol Stack Reference Model
Figure 4 below shows the protocol stack reference model for PWs. The
PW provides the CE with what appears to be a connection to its peer
at the far end. Bits or PDUs from the CE are passed through an
encapsulation layer.
+-------------+ +-------------+
| Emulated | | Emulated |
| Service | | Service |
| (TDM, ATM, | Emulated Service | (TDM, ATM, |
| Ethernet, |<=================================>| Ethernet, |
|Frame Relay, | |Frame Relay, |
| etc. | | etc. |
+-------------+ Pseudo Wire +-------------+
|Encapsulation|<=================================>|Encapsulation|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
|IP/MPLS/L2TP |<=================================>|IP/MPLS/L2TP |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| IP/MPLS/L2TP Network |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+=========/ |=====+
\ /
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 4: PWE3 Protocol Stack Reference Model
3.3. Architecture Assumptions 3.3. Architecture Assumptions
1) The current design is focused on a point-to-point and same-to-same 1) The current design is focused on a point-to-point and same-to-same
service interface at both end of the PW. Only network service interface at both end of the PW. Only network
interworking will be performed at the edge or the PW. Support for interworking will be performed at the edge or the PW. Support for
service interworking is for further study. service interworking is for further study.
2) The initial design of PWE3 is focused on a single homogenous 2) The initial design of PWE3 is focused on a single homogenous
administrative PWD (e.g. PW over MPLS or PW over IP etc. ONLY). administrative PWD (e.g. PW over MPLS or PW over IP etc. ONLY).
Interworking between different pseudo-wire types and the support Interworking between different PW types and the support of inter-
of inter-domain PWs are for further study. domain PWs are for further study.
3) The design of PW will not perfectly emulate the characteristics of 3) The design of PW will not perfectly emulate the characteristics of
the native service. It shall be dependent on both the emulated the native service. It will be dependent on both the emulated
service, as well as on the network implementation. An AS shall be service, as well as on the network implementation. An AS shall be
created for each service to describe the degree of faithfulness of created for each service to describe the degree of faithfulness of
a PW to the native service. a PW to the native service.
4) Only the permanent emulated circuit type (e.g. PVC/PVP) is 4) Only the permanent emulated circuit type (e.g. PVC/PVP) is
considered initially. The switched emulated circuit type (e.g. considered initially. The switched emulated circuit type (e.g.
SVC/SVP) will be for further study. SVC/SVP) will be for further study.
5) The creation and placement of the tunnel to support the PW is not 5) The creation and placement of the PSN tunnel to support the PW is
within the scope. not within the scope.
6) The current PW encapsulation approach considerations are focused 6) The current PW encapsulation approach considerations are focused
on IPv4, IPv6, L2TP, GRE and MPLS. Other encapsulation approach on IPv4, IPv6, L2TP and MPLS. Other encapsulation approach is for
is for further study. further study.
7) Current PW service applications are focused on Ethernet (i.e. 7) Current PW service applications are focused on Ethernet (i.e.
Ethernet II (DIX), 802.3 "raw", Ethernet 802.2, Ethernet SNAP, Ethernet II (DIX), 802.3 "raw", Ethernet 802.2, Ethernet SNAP,
802.3ac VLAN), Frame Relay, ATM, TDM (e.g. DS1, DS3, T1, SONET 802.3ac VLAN), Frame Relay, ATM, TDM (e.g. DS1, DS3, E1, SONET/SDH
etc.) and MPLS. etc.) and MPLS.
8) Within the single administrative PWD, the design of the PW assumes 8) Within the single administrative PWD, the design of the PW assumes
the inheritance of the security mechanism that has been applied to the inheritance of the security mechanism that has been applied to
the emulated services. No PW specific security mechanism will be the emulated services. No PW specific security mechanism will be
specified. specified.
3.4. Comparison of Relevant Applications 3.4. Suitable Applications for PWE3
<Editor's Note: This section will discuss the attributes that make an
application suitable (or not) for PWE3 emulation. This section is
currently under revision. >
When considering PWs as a means of providing a service, the following When considering PWs as a means of providing a service, the following
questions must be asked: questions regarding the application must be considered.
- Preservation of Order - Does the application require in-order - Preservation of Order - Does the application require in-order
delivery of data? delivery of data? Emulation of an application that requires in-
order delivery over a PSN that does not guarantee such delivery may
be difficult.
- Preservation of Timing - Does the application require fine-grain - Preservation of Timing - Does the application require fine-grain
preservation of timing? preservation of timing? If so, the adaptation may be complicated
by providing such timing where it is not normally available.
- Natural Delineation - What is the "natural" boundary for - Natural Delineation - What is the "natural" boundary for
delineation of data for encapsulation? delineation of data for encapsulation? (Note: For bit/byte-
oriented services, such as TDM emulation, this "natural"
delineation may not necessarily be the overriding consideration for
determining the best "chunk" for packetizing the service.)
- Packet Size - Are the encapsulated packets variable or fixed in - Packet Size - Are the encapsulated packets variable or fixed in
size? size?
- Data Rate - Is the data rate presented at the interface fixed or - Data Rate - Is the data rate presented at the interface fixed or
variable? variable?
Figure 2 below shows a summary of the applications relevant to pseudo Figure 5 below shows a summary of the applications relevant to PWs,
wire transport, along with a comparison of their attributes. along with a comparison of their attributes.
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
| Attribute ->|Preserve|Preserve| "Natural" | Packet | Data | |Attribute ->|Preserve|Preserve| "Natural" | Packet | Data |
|Application | Order | Timing | Delineation| Size | Rate | |Application | Order | Timing | Delineation| Size | Rate |
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|TDM Circuits | yes | yes |125 us frame| fixed | fixed | |T1/E1/T3/E3 | yes | yes |125 us frame| fixed | fixed |
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|SONET Circuits | yes | yes |125 us frame| fixed | fixed | |SONET/SDH | yes | yes |125 us frame| fixed | fixed |
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|Frame Relay | yes | no | frame |Variable|Variable| |Frame Relay | yes | no | frame |variable|variable|
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|ATM AAL1 | yes | no | cell | fixed | fixed | |ATM AAL1 | yes | yes | cell | fixed | fixed |
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|ATM AAL2 | yes | no | cell | fixed |variable| |ATM AAL2 | yes | yes | cell | fixed |variable|
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|ATM AAL5 | yes | no |cell or PDU |variable|variable| |ATM AAL5 | yes | no |cell or PDU |variable|variable|
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
|Ethernet | yes | no | frame |variable|variable| |Ethernet | yes | no | frame |variable|variable|
+----------------+--------+--------+------------+--------+--------+ +------------+--------+--------+------------+--------+--------+
Figure 5: Summary of Applications and Attributes
Figure 2: Summary of Applications and Attributes
4. Layer 1 (Circuit) Applications 4. Layer 1 (Circuit) Applications
For these applications the entire bit stream needs to be transported For circuit applications the entire bit stream (or at least the
to the far end. As with SONET transport or ATM CES, the physical payload) needs to be recreated at the far end of the PW. As with ATM
layer coding is terminated and re-generated on the far end. In CES, the physical layer coding is terminated and re-generated on the
addition, framing may be terminated and regenerated, depending on the far end. In addition, framing may be terminated and regenerated,
application. depending on the application.
4.1. Reference Model 4.1. Reference Model
Figure 3 below shows a pair of T1s being carried over a TDM/SONET Figure 6 below shows a pair of T1s being carried over a TDM/SONET
network. The node marked "M" is an M13 multiplexer, while the nodes network. The node marked "M" is an M13 multiplexer, while the nodes
marked "S" are SONET Add-Drop Multiplexers (ADMs). marked "S" are SONET Add-Drop Multiplexers (ADMs). Note that the
physical interface of the circuit may change without affecting the
circuit. For example, the T1s in Figure 6 below enter the network as
physical T1s but exit the network as Virtual Tributaries (VTs) in a
physical OC12.
SONET/TDM Network SONET/TDM Network
____ ___ ____ ____ ___ ____
_/ \___/ \ _/ \__ _/ \___/ \ _/ \__
+------+ Physical / \__/ \ +------+ Physical / \__/ \
|Site A| T1 / +---+ DS3 \ Hub Site |Site A| T1 / +---+ DS3 \ Hub Site
|T1 #1=|=================|\M/|-------------+-----+ \ OC12+------+ |T1 #1=|=================|\M/|-------------+-----+ \ OC12+------+
| | \ |/ \|=============|\ /| \----| | | | \ |/ \|=============|\ /| \----| |
+------+ /\ +---+-------------| \ / |========|=T1 #1| +------+ /\ +---+-------------| \ / |========|=T1 #1|
/ | S | / | | / | S | / | |
+------+ Physical/ +---+-------------| / \ |========|=T1 #2| +------+ Physical/ +---+-------------| / \ |========|=T1 #2|
|Site B| T1 \ |\S/|=============|/ \| \----| | |Site B| T1 \ |\S/|=============|/ \| \----| |
|T1 #2=|=================|/ \|-------------+-----+ / +------+ |T1 #2=|=================|/ \|-------------+-----+ / +------+
| | \ +---+ OC3 __ / | | \ +---+ OC3 __ /
+------+ \ __/ \ / +------+ \ __/ \ /
\ ___ ___ / \_/ \ ___ ___ / \_/
\_/ \____/ \___/ \_/ \____/ \___/
Figure 3: T1/SONET Example Diagram Figure 6: T1/SONET Example Diagram
Figure 4 below shows the same pair of T1s being carried over a packet
network. Here the emulation is performed by the boxes marked "E",
and the routers marked "R" carry the resulting packets. Note that
the emulation, routing and/or SONET functions could be combined in
the same device.
Figure 7 below shows the same pair of T1s being carried over a packet
network. Here the emulation is performed by the PEs marked "PE", and
the routers marked "R" carry the resulting packets. Note that the
PE, routing and/or SONET functions could be combined in the same
device.
SONET/TDM/Packet Network SONET/TDM/Packet Network
____ ___ ____ ____ ___ ____
_/ \___/ \ _/ \__ _/ \___/ \ _/ \__
+------+ Physical / \__/ \_ +------+ Physical /+-+ \__/ \_
|Site A| T1 / +-+ +---+ \ Hub Site |Site A| T1 / | | +---+ \ Hub Site
|T1 #1=|=============|E|=| R | +---+ +-+ +-----+ \ OC12+------+ |T1 #1=|=============|P|=| R | +---+ +-+ +-----+ \ OC12+------+
| | \ +-+ | |===| | | |=|\ /| \----| | | | \ |E| | |===| | | |=|\ /| \----| |
+------+ /\ +---+ | | | | | \ / |========|=T1 #1| +------+ /\+-+ +---+ | | | | | \ / |========|=T1 #1|
/ | R |=|E| | S | / | | / | R |=|P| | S | / | |
+------+ Physical/ +---+ | | | | | / \ |========|=T1 #2| +------+ Physical/ +-+ +---+ | | |E| | / \ |========|=T1 #2|
|Site B| T1 \ +-+ | R |===| | | |=|/ \| \----| | |Site B| T1 \ |P| | R |===| | | |=|/ \| \----| |
|T1 #2=|=============|E|=| | +---+ +-+ +-----+ / +------+ |T1 #2=|=============|E|=| | +---+ +-+ +-----+ / +------+
| | \ +-+ +---+ __ / | | \ | | +---+ __ /
+------+ \ __/ \ / +------+ \ +-+ __/ \ /
\ ___ ___ / \_/ \ ___ ___ / \_/
\_/ \____/ \___/ \_/ \____/ \___/
Figure 4: T1 Emulation Example Diagram Figure 7: T1 Emulation Example Diagram
4.2. Operational Considerations 4.2. Operational Considerations
4.2.1. Transparency 4.2.1. Transparency
Circuits such as T1/E1/T3/E3 lines need a greater degree of Circuits such as T1/E1/T3/E3/SONET/SDH lines need a greater degree of
transparency than Layer 2 services. These circuits may be carrying transparency than Layer 2 services. These circuits may be carrying
the services described in the section on Layer 2 services, but in the the services described in the section on Layer 2 services, but in the
Layer 1 scenario the higher layer application is irrelevant and is Layer 1 scenario the higher layer application is irrelevant and is
ignored. In general, these are "bits in, bits out" applications. ignored. In general, these are "bits in, bits out" applications.
In this application a circuit or bit stream is encapsulated in fixed- In this application a circuit or bit stream is encapsulated in fixed-
size frames that are sent at a fixed rate. The emulated stream must size frames that are sent at a fixed rate. The emulated stream must
be delivered in a reliable and predictable fashion to the far end. be delivered in a reliable and predictable fashion to the far end.
Absolute delay and delay variation (also called jitter or wander) Absolute delay and delay variation (also called jitter or wander)
must be minimized. must be minimized. Excess delay and delay variation may cause
problems with the application carried by the TDM/SONET CEs.
This encapsulation of TDM data must be transparent. The emulated This encapsulation of TDM data must be transparent. The emulated
circuit could be carrying one or more types of data (ATM, Frame circuit could be carrying one or more types of data (ATM, Frame
Relay, TCP/IP, etc.), voice traffic, video or anything else. The Relay, TCP/IP, etc.), voice traffic, video or anything else. The
data is not interpreted; it is simply transported. data is not interpreted; it is simply transported.
4.2.2. Framed Versus Unframed Mode For TDM Circuits 4.2.2. Structured Versus Unstructured Mode For TDM Circuits
As discussed in [ATMCES], emulation of a T1, E1 or other circuit can As discussed in [ATMCES], emulation of a T1, E1 or other circuit can
be done in a framed mode or in an unframed mode. Framed mode be done in a structured (framed) mode or in an unstructured
requires the use of a framer to generate the outgoing framing (unframed) mode. This same distinction can be applied to higher rate
pattern. More importantly, it is needed to detect a LOS condition or circuits such as DS3, E3, and SONET/SDH.
reception of an Alarm Indication Signal (AIS). A framer is also
needed to generate and terminate the Facility Data Link (FDL) Unstructured mode generally involves collecting all bits received
overhead channel used for communication of loopback commands and from a physical port (including transport framing), and packing them
performance reports. The capabilities described in the rest of this into packets for transport through the PSN. The fact that the
section (except for LOS) are predicated on the presence of a framer. received bit stream contains a framed signal is more or less
irrelevant to the adaptation function.
Structured mode requires the use of a framer to identify and
terminate the incoming transport framing, and delineate logical TDM
channels within the TDM bit stream for emulation. In addition, TDM
framers are generally needed to detect maintenance signals such as
Alarm Indication Signal (AIS) and Remote Defect Indication (RDI).
Framers are also used to measure various performance parameters such
as Errored Seconds, Frame Errored Seconds, etc. Lastly, a framer is
needed to generate and terminate the Facility Data Link (FDL) as well
as the SONET/SDH Data Communications Channels (DCCs).
The capabilities described in the rest of this section (except for
LOS) are predicated on the presence of a framer.
4.2.3. Fractional T1/E1 4.2.3. Fractional T1/E1
A fractional T1 or E1 is composed of a number of concatenated DS0s A fractional T1 or E1 is composed of a number of concatenated DS0s
and is sometimes referred to as NxDS0. It may be emulated by and is sometimes referred to as NxDS0. It may be emulated by
replicating the contents of the relevant DS0s at the other end of the replicating the contents of the relevant DS0s at the other end of the
tunnel. The value of the other timeslots and/or framing are tunnel. The value of the other timeslots and/or framing are
irrelevant and are not transported in leased line application. Even irrelevant and are not transported in leased line application. Even
though the framing is not transported, a framer is still needed to though the framing is not transported, a framer is still needed to
delineate the timeslots for encapsulation. delineate the timeslots for encapsulation.
4.2.4. Loopbacks 4.2.4. STS-1/Nc
It is desirable for a PWE node to process loopback messages as The SONET/SDH equivalent to Structured T1/E1 services are STS-1/Nc
defined in [T1.403]. This would allow for isolation of faults in a and their SDH equivalents. For STS-1/Nc services a single SONET
network. It also facilitates the certification of equipment for timeslot or a concatenation of multiple timeslots is used to carry a
operation in a carrier's network. single logical circuit. As with structured T1/E1 services, the
transport framing (i.e. SONET Section and Line Overhead) is
terminated, and only the relevant SONET timeslots are carried through
the packet network. A single physical SONET interface can be the
source of multiple STS-1/Nc services, each of which may be emulated
as an independent PWE3 service.
There are also inband loopbacks that are used for voice equipment. 4.2.5. Loopbacks
These are falling out of favor due to their incompatibility with data
services. A PWE device that implements inband loopbacks must have
the capability to disable them.
4.2.5. Performance Processing It could be useful for a PE to process loopback messages as defined
in [T1.403]. This would allow for isolation of faults in a network.
It also facilitates the certification of equipment for operation in a
carrier's network.
There are also inband loopback commands that are used for voice
equipment. These loopback commands are triggered by patterns carried
in with the data itself. Voice is limited in the patterns it can
present, so it won't falsely mimic the inband loopback command.
These inband commands are falling out of favor due to their
incompatibility with data services. The inband pattern for the
loopback may inadvertently appear in a data stream due to its
arbitrary nature. A PE device that implements inband loopbacks must
have the capability to disable them.
4.2.6. Performance Processing
[T1.403] defines a Network Performance Report Message (NPRM) that [T1.403] defines a Network Performance Report Message (NPRM) that
carry periodic reports on the performance of the link. It is carry periodic reports on the performance of the link. It would be
desirable for a PWE node to generate these messages, as they are useful for a PE to generate these messages, as they are frequently
frequently used for surveillance and trouble-shooting. used for surveillance and trouble-shooting.
4.2.6. LOS/LOF/AIS/RAI 4.2.7. LOS/LOF/AIS
Figure 5 shows an example for the generation of AIS and RAI. Figure 8 shows an example for the generation of AIS and RAI.
<-- Upstream Downstream --> <-- Upstream Downstream -->
LOS +-----+ AIS LOS +-----+ AIS
------X----->|\ /|---------> ------X----->|\ /|--------->
| \ / | | \ / |
| / \ | | / \ |
<------------|/ \|<--------- <------------|/ \|<---------
RAI+Data +-----+ Data RAI/RDI+Data +-----+ Data
Figure 5: Generation of AIS and RAI
A TDM multiplexer, switch or other path-terminating device must
respond to an LOS (Loss of Signal), LOF (Loss of Frame) or AIS (Alarm
Indication Signal) condition (collectively known as "red alarms") by:
- Generating AIS in the "downstream" direction i.e. the same Figure 8: Generation of AIS and RAI/RDI
direction in which the LOS was detected. AIS is conveyed by
sending a certain pattern in the data stream.
- Generating RAI (Remote Alarm Indication, also known as a "Yellow A TDM multiplexer, SONET ADM, switch or other line terminating
Alarm") in the "upstream" direction i.e. in the other direction. equipment (LTE) must respond to an LOS (Loss of Signal), LOF (Loss of
RAI is conveyed by sending a certain pattern in the framing. Note Frame) or AIS (Alarm Indication Signal) condition (traditionally
that RAI does not interfere with or suppress the payload data. known as "red alarms") by generating AIS in the "downstream"
direction i.e. the same direction in which the LOS was detected. AIS
is conveyed by sending a certain pattern in the data stream. It may
also send RAI (or RDI in SONET) in the "upstream" direction i.e. the
opposite direction from that where the LOS was detected. See section
9 of [T1.403] for more information on T1 AIS and RAI. See section
section 6.2.1 in [GR253] for more information on the SONET AIS-L and
RDI-L signals.
Bandwidth can be saved by suppressing the AIS signal in the emulated Bandwidth can be saved by suppressing the AIS signal in the emulated
stream and sending instead an indication in the control overhead. stream and sending instead an indication in the control overhead.
This also applies to a received AIS signal. [MALIS] discusses the This also applies to a received AIS signal. [MALIS] discusses the
propagation of AIS using the pointer bits in the TDM control word. propagation of AIS using the pointer bits in the TDM control word.
A device emulating TDM circuit must either replicate the AIS A device emulating TDM circuit must either replicate the AIS
indication or indicate this condition in the control overhead. indication or indicate this condition in the control overhead.
4.2.7. SONET/SDH STS Unequipped 4.2.8. SONET/SDH STS Unequipped
The "STS Unequipped" indication may be treated in a fashion similar The "STS Unequipped" indication may be treated in a fashion similar
to that for LOS/AIS. Bandwidth can be saved by suppressing the to that for LOS/AIS. As discussed in [MALIS], bandwidth can be saved
payload in the emulated stream and sending instead an indication in by suppressing the payload in the emulated stream and sending instead
the control overhead. an indication in the control overhead.
4.3. Encapsulations 4.3. Encapsulations
4.3.1. Criteria
Encapsulation options for TDM services may be compared on the Encapsulation options for TDM services may be compared on the
following criteria. following criteria.
- Timing - TDM services are very sensitive to timing and timing - Timing - TDM services are very sensitive to timing and timing
variations ("jitter"). The encapsulation may need to provide variations ("jitter"). The encapsulation may need to provide
additional information to help convey timing. additional information (such as [RTP] timestamps) to help convey
timing across the PW.
- Line Signals - The encapsulation should provide a means to convey - Line Signals - The encapsulation should provide a means to convey
signals such as AIS and line conditions such as LOF. signals such as AIS and line conditions such as LOF.
- The encapsulation should minimize overhead. - The encapsulation should minimize overhead.
4.3.2. SONET Encapsulation 4.4. Timing
4.3.2.1. SPE In the recent Ken Burns Jazz television series, it was said of Louis
Armstrong that he was very economical with his notes, but that the
timing of those notes was everything. The timing of the
reconstructed bit stream is similarly important. This section
describes the various approaches to this problem. A summary is also
provided at the end of the section.
The format of the SPE (Synchronous Payload Envelope) for SONET is 4.4.1. Reference Model
defined in [GR253]. This mapping is used in [MALIS] as the basis for
the encapsulation format. The advantages of this approach include:
- It is defined for multiples of 50.112 Mpbs. Consider the example network shown in Figure 9. In this network, CE1
and CE2 are connected by a PW provided by PE1, S1, S2 and PE2.
- The structures and methods for synchronization are well defined. +---------------+ +---------------+
| PE1 | | PE2 | G
| | | | |
| | | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ ^ ^ | | | ^ ^ ^ | ^ ^
| | | |B | | | |<------+------>| |D | | | | | |
| A | +--+ +--+-C | | | +--+ +--+-E | F |
| +---------------+ +-+ +---------------+ |
| |I| |
| +-+ |
| | |
+-----------------------------+-----------------------------+
- The line overhead is suppressed. Where:
"CEn" is the TDM edge device
"PEn" is the PE adaptation device
"Sn" is a core switch
"A" - "I" are clocks
"=" is the T1 Bit Stream
":" is the switched connection
"Phy" is a physical interface
"Enc" is a PWE3 encapsulation device
"Dec" is a PWE3 decapsulation device
- The SPE can be extracted from the packet and fed into a SONET Figure 9: Timing Recovery Reference Diagram
framer. This facilitates interworking with SONET systems, as shown
in Figure 4.
The disadvantages include: For this application to work, CE2 needs to be clocked (by clock E) at
the same frequency as CE1 (which is being clocked by clock A). A
jitter correction buffer at PE2 can handle short-term differences
between these two clocks, but over time any absolute difference is
going to cause this buffer to overflow or underflow.
- There is no support for rates below STS-1. Bits are clocked into an encapsulation function in PE1 according to
clock B, which is recovered from the incoming data stream. Clocks A
and B will have the same frequency.
- There is no support for rates other than multiples of 50.112 Mbps. The bits are packed into frames and clocked out according to clock C.
Clock C could be related to clock B, but in most cases these clocks
are completely independent.
4.3.2.2. Section/Line The frames arrive at switch S1, and are clocked out according to the
internal oscillator on the output interface of switch S1. The frames
will depart at the same average rate at which they arrived, but the
instantaneous rate will be different on each side of S1. Note that
there could be short-term variations due to congestion, but S1 can't
experience long-term congestion with respect to the frames carrying
emulated data, or the service won't work.
This is similar to an SPE, but the section and line overhead are The frames travel on to switch S2, which again forwards them. Note
preserved. The advantages of this approach include: that switch S2 introduces yet another clock, which it uses to
transmit the packets toward PE2. Again the average rate is
preserved, but the instantaneous rate will vary.
- It is completely transparent. Any compatibility issues go away. The frames arrive at PE2 and are clocked into the decapsulation
function when they arrive (using clock D). Note that clock D will
have the same average frequency as A and B, but will have short-term
variations. The bits are clocked out of the FIFO according to clock
E. Clock F at CE2 is recovered from the bit stream and therefore
runs at the same frequency as clock E.
- The interface equipment is very simple because no framer is 4.4.2. Recreating the Timing
required. The output of an optical transceiver can be fed directly
into the packet generation function.
The disadvantages include: The big question is: where does clock E in Figure 9 come from? There
are 5 possibilities, and these are detailed in the following
sections.
- In SONET, the user data is carried in the SPE and/or VTs, which are 1) Clock E is derived from an external source such as clock I or B
path functions. By analogy, an emulation device should act like (indirectly via A) at CE1 and G (indirectly via H) at CE2. This
SONET gear that terminates a section or path. Transporting the method is described in the "External Timing" section below.
section or path overhead seems to violate the spirit of the SONET
path/line/section model.
4.3.2.3. VT 2) Clock E could be derived from Clock I and the pointers. This
approach is described in the "SONET Pointer Justification" section
below.
SONET VT mapping into an SPE is defined for T1, E1, E3 and T3. An 3) Clock E is derived from the average rate of Clock D. This is the
example of VT1.5 mapping is shown in Figure 6 below, reproduced from "Adaptive Timing" scenario described in a subsequent section.
[GR253].
1 2 3 * * * 29 30 31 32 * * * 58 59 60 61 * * * 87 4) Clock E is derived from a combination of the local oscillator at
+--+------------------+-+------------------+-+------------------+ PE2 and received SRTS timestamps. The "Differential (SRTS)"
1 |J1| Byte 1 (V1-V4) |R| | | | |R| | | | | section below describes this approach.
+--+---+---+------+---+-+------------------+-+------------------+
2 |B3|VT | | | |R| | | | |R| | | | |
+--+1.5| | | +-+---+---+------+---+-+------------------+
3 |C2| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
4 |G1| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
5 |F2| | | | |R| | | | |R| | | | |
+--|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|
6 |H4| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
7 |Z3| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
8 |Z4| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
9 |Z5| | | | |R| | | | |R| | | | |
+--+---+---+------+---+-+---+---+------+---+-+------------------+
| | |
+-- Path Overhead +--------------------+-- Fixed Stuffs
Figure 6: SPE Mapping of VT1.5 5) Clock E is derived from inband RTP timestamps. This method is
discussed in the "RTP" section below.
The advantages of this approach include: 4.4.2.1. External Timing
- This mapping is well defined. The simplest method for communicating timing from one end of a system
to the other is an external timing source, such as clock I in Figure
9. This external timing source is normally a T1 or E1, but it could
be delivered via SONET or a GPS receiver. Its 8 KHz frame rate is
extracted and used to directly clock the reconstructed data streams,
or as an input to a phase-locked loop to synthesize the desired
clock. The drawback to this method is that a common external clock
is not commonly available in a data network or in a multi-carrier
network.
- Commercial silicon is available to implement this function. Note that clock I may actually be two separate clocks of a particular
accuracy or stratum. The difference in frequency will eventually
cause the FIFO to slip, but if the clock is of a high enough accuracy
then the slips will be very infrequent. For example, a stratum 1
clock is accurate to one part in 10**11 [G.811]. This gives a
frequency slip rate of 15.4**-6 bit-slip/sec:
- This mapping is fairly efficient. It requires 27 bytes per VT1.5, slip rate = 1.544 Mbps * 10**-11
which is an overhead of about 10%. = 15.4**-6 bit-slip/sec
The disadvantages include: Taking the reciprocal yields 18 hours/bit-slip:
- This mapping is inefficient for transport of a few circuits. The bit slip period = 1 / ( 15.4**-6 bit-slip/sec * 3600 s/h)
whole SPE must be sent, regardless of how many circuits are = 18 hours/bit-slip.
provisioned.
4.3.3. ATM AAL1 Encapsulation A typical multiplexer has a buffer that is two frames deep. Assuming
that it starts out centered, the expected time for a slip would be
almost 5 months:
ATM AAL1/2 is the mapping defined in [I.363.1] and [I.363.2]. It is frame slip period = 18 hours/bit-slip * 193 bits/frame
used in [ANAVI] as the basis for the encapsulation. The advantages = 3474 hours
of this approach include: = 145 days
= 4.8 months
- ATM AAL1 is defined for T1, E1, E3 and T3. This slip rate could be higher or lower depending on the bit rate,
clock accuracy and the depth of the FIFO.
- ATM cells are fairly small. This allows for a low capture delay 4.4.2.2. SONET Pointer Justification
and low queuing delay.
- ATM cells include SRTS timing information. SONET defines layers of pointers that allow for the multiplexing and
transmission of asynchronous signals. These pointers convey the
timing of the carried signal with respect to the timing of the
encapsulating signal. Each SONET ADM must manipulate these pointers
to preserve the timing. This method has the advantage of being well-
defined and understood.
The disadvantages include: One way to apply this method to a packet-based network would be to
ensure that all of the links on a given path are synchronous. This
would be difficult for Gigabit Ethernet or POS links.
- There is no definition for rates higher than T3. This means that a Another way would be for each router to update the pointers as the
different encapsulation format would have to be used for STS-1 and packet traversed the router. This would be compute intensive.
higher rates.
- There are 5 bytes of overhead for each 48 bytes of payload. This The method defined in [MALIS] requires pointer manipulation only at
can be overcome by removing the header at one end of the link and the end points. It does require an external clock as a reference for
restoring it at the other. the pointer adjustments.
- Telcordia asserts that its U.S. Patent No 5,260,978 for Synchronous 4.4.2.3. Adaptive Timing
Residual Timestamp (SRTS) Timing Recovery in a Broadband Network
may apply to the ATM Adaptation Layer Type 1 (AAL1). Adaptive timing is used when an external reference is not available.
[ATMCES] describes adaptive timing as follows:
The adaptive technique does not require a network-wide
synchronization signal to regenerate the input Service
clock at the output IWF. A variety of techniques could be
used to implement Adaptive clock recovery. For example,
the depth of the reassembly buffer in the output IWF could
be monitored:
1. When the buffer depth is too great or tends to increase
with time, the frequency of the Service clock could be
increased to cause the buffer to drain more quickly.
2. When the buffer contains fewer than the configured
number of bits, the Service clock could be slowed to
cause the buffer to drain less quickly. Wander may be
introduced by the Adaptive clock recovery technique if
there is a low-frequency component to the Cell Delay
Variation inserted by the ATM network carrying cells
from the input to output IWF.
Careful design is required to make adaptive timing work
well. The instantaneous buffer depth must be filtered to
extract the average frequency and to reject the jitter and
wander.
Adaptive timing is ideal for many network applications where there is
no external timing reference available (needed for SRTS), and where
the packet rate is decoupled from the line rate (as in a routed
network). Adaptive timing may not meet the requirements of [G.823],
[G.824] and other similar specifications.
4.4.2.4. Differential (SRTS)
[ATMCES] describes the SRTS (Synchronous Residual Time Stamp) method:
The SRTS technique measures the Service Interface input
clock frequency against a network-wide synchronization
signal that must be present in the IWF, and sends
difference signals, called Residual Time Stamps, in the
AAL1 header to the reassembly IWF. At the output IWF, the
differences can be combined with the network-wide
synchronization signal to re-create the input Service
Interface clock.
The requirement for a network-wide signal is reasonable in a Telco or
SONET environment, where such clocks are commonly available. It may
be problematic in a packet network.
Here is the correspondence between the clocks in Figure 9
and.[I.363.1].
Description I.363.1 Figure 9
------------------------------------------
Service Clock Fs A, B
Network Clock Fn C
Derived Reference Fnx Based on C
4.4.2.5. RTP
[RTP] uses an absolute timestamp to play out the bits at the same
rate that they were received and packetized. RTCP (RTP Control
Protocol) provides a means to synchronize the transmit and receive
clocks.
4.4.2.5.1. RTP Timestamps
Section 4 of [RTP] defines a timestamp that is either 32-bits or
64-bits in size:
Wallclock time (absolute time) is represented using the
timestamp format of the Network Time Protocol (NTP), which
is in seconds relative to 0h UTC on 1 January 1900 [NTP].
The full resolution NTP timestamp is a 64-bit unsigned
fixed-point number with the integer part in the first 32
bits and the fractional part in the last 32 bits. In some
fields where a more compact representation is appropriate,
only the middle 32 bits are used; that is, the low 16 bits
of the integer part and the high 16 bits of the fractional
part. The high 16 bits of the integer part must be
determined independently.
A 32-bit absolute time stamp with a 16-bit fractional part would give
a 15 us granularity (= 1/65535), which is too coarse for circuit
emulation. This means that the 64-bit timestamp must be used, with a
granularity of 23 ns.
The transmit timestamps are created according to clocks B and C at
PE1 and interpreted according to clocks D and E at PE2. These two
oscillators will vary by some amount, even if they are very accurate.
This drift means that RTCP, NTP or some other means must be used to
synchronize the clocks at each end.
4.4.3. Summary of Timing Recovery Methods
All of the previously described methods for timing recovery can be
made to work for Layer 1 circuit services. How then can we compare
them? Here are some criteria:
- Is an external timing source required? This might be a direct
timing source as described in "External Timing", or it could be an
indirect source as with SRTS.
- Must the PE synthesize clocks? Synthesis of clocks generally
requires a Phase-Locked Loop (PLL) to create one clock from
another.
- Is the method provably correct? Some methods such as external
timing and SRTS can be proven to meet specifications. The
performance of others, such as adaptive timing, is more dependent
on particular implementations.
Figure 10 below shows a summary of the methods for timing recovery.
+-----------------------------+------+-----+-----+----+-----+
| Method->| Ext. |SONET|SRTS |RTP/|Adap-|
|Parameter |Source| Ptr | |RTCP|tive |
+-----------------------------+------+-----+-----+----+-----+
|External timing required? | yes | yes | yes | no | no |
|Clock synthesis? | no | yes | yes | yes| yes |
|Provably correct? | yes | yes | yes | ? | ? |
+-----------------------------+------+-----+-----+----+-----+
Figure 10: Summary of Timing Recovery Methods
5. Layer 2 (Packet/Cell) Applications 5. Layer 2 (Packet/Cell) Applications
5.1. Layer 2 PW Reference Model 5.1. Layer 2 PW Reference Model
Figure 7 below shows the reference model for Layer 2 PWs. The layer Figure 11 below shows the reference model for Layer 2 PWs. The Layer
2 emulated protocols/services include ATM VCC, ATM VPC, Frame Relay 2 emulated protocols/services include ATM VCC, ATM VPC, Frame Relay
DLCI, IEEE 802.1Q VLAN, IEEE 802.3x link, etc. The nodes marked "S" DLCI, IEEE 802.1Q VLAN, IEEE 802.3x link, etc. The nodes marked "S"
are protocol-specific switches e.g. Frame Relay switches. are protocol-specific switches e.g. Frame Relay switches.
Carrier A Carrier B Carrier A Carrier B
____ ___ ____ ___
Layer 2 _/ \___/ \ ___ Layer 2 _/ \___/ \ ___
+-------+ Link / \____ / \__ Layer 2 +-------+ Link / \____ / \__ Layer 2
|Site A |---------/ +---+ \ / \ Link |Site A |---------/ +---+ \ / \ Link
| SE#1=|===============|\S/| || +-----+ \ +------+ | CE#1=|===============|\S/| || +-----+ \ +------+
| |--------\ |/ \|===============|\ /| \--|Site C| | |--------\ |/ \|===============|\ /| \--|Site C|
+-------+ \ +---+ || | \ / |=====|=SE#3 | +-------+ \ +---+ || | \ / |=====|=CE#3 |
/ || | S | / | | / || | S | / | |
+-------+ / +---+ || | / \ |=====|=SE#4 | +-------+ / +---+ || | / \ |=====|=CE#4 |
|Site B |--------\ |\S/|===============|/ \| \--| | |Site B |--------\ |\S/|===============|/ \| \--| |
| SE#2=|===============|/ \| || +-----+ _/ +------+ | CE#2=|===============|/ \| || +-----+ _/ +------+
| |---------\ +---+ / \__ / | |---------\ +---+ / \__ /
+-------+ \ / \ _/ +-------+ \ / \ _/
\ ___ ___ \ \_/ \ ___ ___ \ \_/
\_/ \___/ \___/ \_/ \___/ \___/
Figure 7: Layer 2 Interconnect Reference Model Figure 11: Layer 2 Interconnect Reference Model
Figure 8 below shows the reference model for PW emulation of Layer 2 Figure 12 below shows the reference model for PW emulation of Layer 2
services. services.
Carrier A Carrier B Carrier A Carrier B
____ ___ ____ ___
Layer 2 _/ \___/ \ ___ Layer 2 _/ \___/ \ ___
+-------+ Link / \____ / \__ Layer 2 +-------+ Link /+-+ \____ / \__ Layer 2
|Site A |--------/ +-+ +---+ +---+ \ / \ Link |Site A |--------/ |P| +---+ +---+ \ / \ Link
| SE#1=|==========|E|=| R | | R | +-+ | | +-----+ \ +------+ | CE#1=|==========|W|=| R | | R | +-+ | | +-----+ \ +------+
| |-------\ | | | |==| |=| |=|==|=|\ /| | |Site C| | |-------\ |E| | |==| |=| |=|==|=|\ /| | |Site C|
+-------+ \ +-+ +---+ +---+ | | | | | \ / |=|===|=SE#3 | +-------+ \ +-+ +---+ +---+ |P| | | | \ / |=|===|=CE#3 |
/ |E| | | | F | | | | /\ |W| | | | F | | | |
+-------+ / +-+ +---+ +---+ | | | | | / \ |=|===|=SE#4 | +-------+ / +-+ +---+ +---+ |E| | | | / \ |=|===|=CE#4 |
|Site B |-------\ |E|=| R |==| R |=| |=|==|=|/ \| | | | |Site B |-------\ |P|=| R |==| R |=| |=|==|=|/ \| | | |
| SE#2=|==========| | | | | | | | | | +-----+ | +------+ | CE#2=|==========|W| | | | | | | | | +-----+ | +------+
| |--------\ +-+ +---+ +---+ +-+ | | | | |--------\ |E| +---+ +---+ +-+ | | |
+-------+ \ / \_______/ +-------+ \+-+ / \_______/
\ / \ /
\ _ __ / \ _ __ /
\_/ \___/ \____/ \_/ \___/ \____/
Figure 8: Layer 2 PW Emulation Figure 12: Layer 2 PW Emulation
5.2. Ethernet 5.2. Ethernet
5.2.1. Reference Model Scope 5.2.1. Reference Model Scope
PW transport of Ethernet operates as a point-to-point trunking PW carriage of Ethernet operates as point-to-point trunking in a non-
transport in a non-shared medium. The Ethernet interface can operate shared medium. The Ethernet interface can operate in a half-duplex
in a half-duplex or full-duplex mode. Control functions such as IEEE or full-duplex mode. Control functions such as IEEE 802.3 Carrier
802.3 Carrier Sense Multiple Access with Collision Detection Sense Multiple Access with Collision Detection (CSMA/CD)[802.3] and
(CSMA/CD)[802.3] and IEEE 802.1D Spanning Tree [802.1D] are not IEEE 802.1D Spanning Tree [802.1D] are not applicable nor within the
applicable nor within the scope of PWs. However, the PW shall scope of PWs. However, the PW shall conform to the service
conform to the service definitions as defined in IEEE 802.1P,Q definitions as defined in IEEE 802.1P,Q [802.1Q], as required. Also,
[802.1Q], as required. Also, it shall support all Ethernet framing it shall support all Ethernet framing i.e. Ethernet Frame and IEEE
i.e. Ethernet Frame and IEEE 802.3x including IEEE 802.3ac VLAN 802.3x including IEEE 802.3ac VLAN Tagging [802.3] as well as Jumbo
Tagging [802.3ac] as well as Jumbo Frame. Frame.
5.2.2. Operational Considerations 5.2.2. Operational Considerations
5.2.2.1. Operational Modes 5.2.2.1. Operational Modes
The design of the Ethernet PW must consider the support of the two The design of the Ethernet PW must consider the support of the two
operational modes in this framework: operational modes in this framework. Both modes shall be supported
for all Ethernet interfaces, i.e. from 10 Mbps to 10,000 Mbps, and
Both modes shall be supported for all Ethernet interfaces, i.e. from the design of the Ethernet PW functions shall be agnostic to the
10 Mbps to 10,000 Mbps, and the design of the Ethernet PW functions Ethernet's link capacity. Both modes shall transparently support the
shall be agnostic to the Ethernet's link capacity. address resolution protocols, i.e. ARP, InverseARP, proxy ARP and
Ethernet-based control protocol (e.g. Generic Attribute Registration
Protocol (GARP), GARP VLAN Registration Protocol (GVRP) etc.).
Both modes shall support the transparent transport of the address - Opaque Trunking - In this mode, the ingress PE shall relay all of
resolution protocols, i.e. ARP, InverseARP, proxy ARP and Ethernet- the traffic from an Ethernet port into the PW.
based control protocol (e.g. Generic Attribute Registration Protocol
(GARP), GARP VLAN Registration Protocol (GVRP) etc.).
- Ethernet Trunking - In this mode, the trunking access pays - Transparent Trunking - This mode is particularly designed for
attention only to the MAC header's port information or other MAC support of Virtual LANs (VLAN). VLAN types include Port-based
header information e.g. MAC address, protocol type etc. The VLANs, MAC-Address-Based VLANs, IP-Based VLANs, 802.1Q Tag-based
processing rules, e.g. classification, filtering, shall be based on VLANs and 802.10 Security-based VLANs.
configurable policy.
- Virtual LAN (VLAN) Transport - In this mode, a link can carry the The ingress PE may pay attention to the MAC header and other
traffic of multiple VLANs through the tagging scheme as specified relevant VLAN classification information based on the configuration
in [802.1Q]. The Ethernet PW shall carry multiple VLANs traffic policy. The Ethernet PW shall carry multiple VLANs traffic and can
and can extend VLANs across the PWD. Each frame received at the extend VLANs across the PWD. In the case when 802.1Q Tag-based
trunking access associated with a particular VLAN indicated by the VLAN is configured, if the received frame is tagged with a NULL
given VLAN_ID. If the received frame is tagged with a NULL
VLAN_ID, it will be associated with the VLAN equal to the Port's VLAN_ID, it will be associated with the VLAN equal to the Port's
default VLAN. At frame transmission, all frames that are sent in default VLAN. At frame transmission, all frames that are
this mode shall be tagged except for those assigned for the default associated with 802.1Q Tag-based VLAN shall be tagged except for
VLAN. those assigned for the default VLAN.
The PWE may provide translation of the VLAN_ID in order to The PE may provide translation of the VLAN_ID in order to
facilitate deployment. Note that this does not increase the facilitate deployment. Note that this does not increase the
VLAN_ID space, so it has no effect on scalability. VLAN_ID space, so it has no effect on scalability.
5.2.2.2. Quality Of Service Support Considerations 5.2.2.2. Quality Of Service Support Considerations
The Ethernet AS shall describe the faithfulness of the PW with The Ethernet AS shall describe the faithfulness of the PW with
respect to these attributes described in IEEE 802.1p [802.1Q]. respect to these attributes described in IEEE 802.1p [802.1Q].
- Service Availability - Service availability is measured as ratio - Service Availability - Service availability is measured as ratio
between MAC service is unavailable and available. between times when MAC service is unavailable and when it is
available.
- Frame Loss - The MAC service does not provide guarantees delivery - Frame Loss - The MAC service does not provide guaranteed delivery
of service data units. However, the Ethernet PW system should of service data units. However, the Ethernet PW system should
consider monitoring frame loss. consider monitoring frame loss.
- Frame Misorder - The MAC service does not permit reordering frames - Frame Misorder - The MAC service does not permit reordering frames
within the same user-priority for a source and destination address within the same user-priority for a source and destination address
pair. pair.
- Frame Duplication - The MAC service does not permit duplicating - Frame Duplication - The MAC service does not permit duplicating
frames. frames.
skipping to change at page 23, line 37 skipping to change at page 28, line 25
- Undetected Frame Error Rate - By using the Frame Checksum (FCS) - Undetected Frame Error Rate - By using the Frame Checksum (FCS)
calculation for each frame, the undetected frame error rate should calculation for each frame, the undetected frame error rate should
be low. be low.
- Maximum Service Data Unit Size - The maximum service data unit size - Maximum Service Data Unit Size - The maximum service data unit size
is dependent on the access media used. In general, it is the is dependent on the access media used. In general, it is the
lowest common denominator of the two adjacent Ethernet interface. lowest common denominator of the two adjacent Ethernet interface.
- Priority Tags and Traffic Classes - IEEE 802.1p defines eight - Priority Tags and Traffic Classes - IEEE 802.1p defines eight
traffic classes (priority). These are ignored by the PWE. traffic classes (priority). The PRI bits on the VLAN fields should
be carried transparently over the PW. COS differentiation on the
PW level based on the received 802.1p bits is possible but is out-
of-scope.
5.3. Frame Relay 5.3. Frame Relay
5.3.1. Reference Model 5.3.1. Reference Model
Frame Relay service offerings often have a different physical format Frame Relay service offerings often have a different physical format
and speed at each end of the link. For example, a hub and spoke and speed at each end of the link. For example, a hub and spoke
deployment of Frame Relay might provide fractional T1 access at the deployment of Frame Relay might provide fractional T1 access at the
spokes and a clear channel T3 to the hub. The Virtual Circuits (VCs) spokes and a clear channel T3 to the hub. The Virtual Circuits (VCs)
are aggregated by switches in the Frame Relay network. This is shown are aggregated by switches in the Frame Relay network. This is shown
in figure 9 below, where the Frame Relay switches are marked with an in figure 13 below, where the Frame Relay switches are marked with an
"F". "F".
Wide Area Frame Relay Network Wide Area Frame Relay Network
Carrier A Carrier B Carrier A Carrier B
____ ___ ____ ___
Fractional _/ \___/ \ ___ Fractional _/ \___/ \ ___
+------+ T1 / \____ / \__ +------+ T1 / \____ / \__
|Site A|-----------/ +---+ \ / \ Hub Site |Site A|-----------/ +---+ \ / \ Hub Site
|VC #1=|=================|\F/| || +-----+ \ DS3+------+ |VC #1=|=================|\F/| || +-----+ \ DS3+------+
skipping to change at page 24, line 36 skipping to change at page 29, line 24
+------+ \ +---+ || | \ / |======|=VC #1| +------+ \ +---+ || | \ / |======|=VC #1|
/\ || | F | / | | /\ || | F | / | |
+------+ / +---+ || | / \ |======|=VC #2| +------+ / +---+ || | / \ |======|=VC #2|
|Site B|----------\ |\F/|===============|/ \| \---| | |Site B|----------\ |\F/|===============|/ \| \---| |
|VC #2=|=================|/ \| || +-----+ _/ +------+ |VC #2=|=================|/ \| || +-----+ _/ +------+
| |-----------\ +---+ / \__ / | |-----------\ +---+ / \__ /
+------+ Trans- \ / \ _/ +------+ Trans- \ / \ _/
Atlantic E1 \ ___ ___ \ \_/ Atlantic E1 \ ___ ___ \ \_/
\_/ \___/ \___/ \_/ \___/ \___/
Figure 9: Frame Relay Example Model Figure 13: Frame Relay Example Model
Figure 10 shows an emulated network, where Carrier "A" is providing a Figure 14 shows an emulated network, where Carrier "A" is providing a
transparent Frame Relay emulation connection to Carrier "B". Here transparent Frame Relay emulation connection to Carrier "B".
the emulation is performed by the boxes marked "E", and the resulting
packets are carried by the routers marked "R". In this case, the
emulated VCs can transparently carry the PVC status signaling (if
any) and need not perform any higher layer function. Also, note that
the emulation and routing functions could be combined in the same
device.
Wide Area Frame Relay/Router Network Wide Area Frame Relay/Router Network
Carrier A Carrier B Carrier A Carrier B
____ ___ ____ ___
Fractional _/ \___/ \ ___ Fractional _/ \___/ \ ___
+------+ T1 / \____ / \__ +------+ T1 /+-+ \____ / \__
|Site A|------------/ +-+ +---+ \ / \ Hub Site |Site A|------------/ | | +---+ \ / \ Hub Site
|VC #1=|==============|E|=| R | +---+ +-+ || +-----+ \ DS3+------+ |VC #1=|==============|P|=| R | +---+ +-+ || +-----+ \ DS3+------+
| |-----------\ +-+ | |==| |=| |====|\ /| \---| | | |-----------\ |E| | |==| |=| |====|\ /| \---| |
+------+ \ +---+ | | | | || | \ / |======|=VC #1| +------+ \ +-+ +---+ | | | | || | \ / |======|=VC #1|
/ \ | R | |E| || | F | / | | / \ | R | |P| || | F | / | |
+------+ / +---+ | | | | || | / \ |======|=VC #2| +------+ / +-+ +---+ | | |E| || | / \ |======|=VC #2|
|Site B|----------\ +-+ | R |==| |=| |====|/ \| \---| | |Site B|----------\ |P| | R |==| |=| |====|/ \| \---| |
|VC #2=|==============|E|=| | +---+ +-+ || +-----+ / +------+ |VC #2=|==============|E|=| | +---+ +-+ || +-----+ / +------+
| |-----------\ +-+ +---+ / \_ / | |-----------\ | | +---+ / \_ /
+------+ Trans- \ / \ _/ +------+ Trans- \ +-+ / \ _/
Atlantic E1 \___ ___ __ \ \__/ Atlantic E1 \___ ___ __ \ \__/
\_/ \___/ \__/ \_/ \___/ \__/
Figure 10: Frame Relay Emulation Example Diagram For Transparent Figure 14: Frame Relay Emulation Example Diagram For Transparent
Emulation Emulation
Here the emulation is performed by the PEs marked "PE", and the
resulting packets are carried by the routers marked "R". In this
case, the emulated VCs can transparently carry the PVC status
signaling (if any) and need not perform any higher layer function.
Also, note that the emulation and routing functions could be combined
in the same device.
If the Frame Relay switches are to be completely eliminated (as shown If the Frame Relay switches are to be completely eliminated (as shown
in figure 11 below), then the emulation service must implement Frame in figure 15 below), then the emulation service must implement Frame
Relay PVC status signaling and/or signaling for SVCs. As previously Relay PVC status signaling and/or connection signaling for SVCs. As
noted, the emulation and routing functions could be combined in the previously noted, the PE and routing functions could be combined in
same device. the same device.
Wide Area Frame Relay/Router Network Wide Area Frame Relay/Router Network
Carrier A Carrier B Carrier A Carrier B
____ ___ ____ ___
Fractional _/ \___/ \ _____ Fractional _/ \___/ \ _____
+------+ T1 / \____ / \__ +------+ T1 /+-+ \____ / \__
|Site A|----------/ +-+ +---+ \ / \ Hub Site |Site A|----------/ | | +---+ \ / \ Hub Site
|VC #1=|============|E|=| R | +---+ +-+ || \ DS3 +------+ |VC #1=|============|P|=| R | +---+ +-+ || \ DS3 +------+
| |---------\ +-+ | |==| |=| | || \----| | | |---------\ |E| | |==| |=| | || \----| |
+------+ \ +---+ | | | |====================|=VC #1| +------+ \ +-+ +---+ | | | |====================|=VC #1|
/\ | R | |E| || / | | /\ | R | |P| || / | |
+------+ / +---+ | | | |====================|=VC #2| +------+ / +-+ +---+ | | |E|====================|=VC #2|
|Site B|---------\ +-+ | R |==| |=| | || \----| | |Site B|---------\ |P| | R |==| |=| | || \----| |
|VC #2=|============|E|=| | +---+ +-+ || _/ +------+ |VC #2=|============|E|=| | +---+ +-+ || _/ +------+
| |----------\ +-+ +---+ / \__ / | |----------\ | | +---+ / \__ /
+------+ Trans- \ / \ _/ +------+ Trans- \+-+ / \ _/
Atlantic E1 \___ ___ _ \ \__/ Atlantic E1 \___ ___ _ \ \__/
\_/ \__/ \___/ \_/ \__/ \___/
Figure 11: Frame Relay Emulation Example Diagram For Non-Transparent Figure 15: Frame Relay Emulation Example Diagram For Non-Transparent
Emulation Emulation
5.3.2. Operational Considerations 5.3.2. Operational Considerations
Frame Relay provides a connection-oriented circuit-based transport. Frame Relay provides a connection-oriented circuit-based carriage of
There are two types of virtual circuits supported in Frame Relay: variable-sized frames. There are two types of virtual circuits
Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits supported in Frame Relay: Permanent Virtual Circuits (PVCs) and
(SVCs). The following sections describe the considerations to Switched Virtual Circuits (SVCs). The following sections describe
support the operation of Frame Relay over the PW. the considerations to support the operation of Frame Relay over the
PW.
5.3.2.1. Frame Sequence 5.3.2.1. Frame Sequence
The PW must deliver frames in the proper sequence. The PW must deliver frames in the proper sequence.
5.3.2.2. Frame Size 5.3.2.2. Frame Size
In general, the maximum frame size for Frame Relay is 1600 bytes per In general, the maximum frame size for Frame Relay is 1600 bytes per
[FRF.1.2]. This can be made larger in some implementations. If the [FRF.1.2]. This can be made larger in some implementations. If the
MTU of the PW is less than (1600 bytes - size of PW headers), a MTU of the PW is less than (1600 bytes - size of PW headers), a
fragmentation and reassembly mechanism may be needed. fragmentation and reassembly mechanism may be needed.
5.3.2.3. End-to-end Transport Characteristics 5.3.2.3. End-to-End Characteristics
[FRF.5] and [FRF.13] define a set of traffic parameters to support [FRF.5] and [FRF.13] define a set of traffic parameters to support
Service Level Agreements (SLAs). The design of the PW should Service Level Agreements (SLAs). The design of the PW may be
preserve these end-to-end transport characteristics. required to preserve these end-to-end transport characteristics.
5.3.2.4. Connection Management and Congestion Control 5.3.2.4. Connection Management and Congestion Control
Each Frame Relay header contains some connection management Each Frame Relay header contains some connection management
information, including information, including
- a command/response (CR) bit - a command/response (CR) bit
- a discard eligibility (DE) bit - a discard eligibility (DE) bit
- a connection ID (DLCI) - a connection ID (DLCI)
- an address extension indicator (EA) - an address extension indicator (EA)
- Forward/Backward Congestion Notification (FECN/BECN). - Forward/Backward Congestion Notification (FECN/BECN). Figure 16
shows an example of how BECN and FECN are sent.
--Congestion->
+-----+ Data+FECN
------------>|\ /|--------->
| \ / |
| / \ |
<------------|/ \|<---------
BECN+Data +-----+ Data
Figure 16: Generation of BECN and FECN
All of this information is vital to the integrity of the Frame Relay All of this information is vital to the integrity of the Frame Relay
circuit. The Frame Relay PW AS shall define an efficient but circuit. The Frame Relay PW AS must define a means to preserve such
optimized approach to transport such information across the PWD. information across the PWD.
5.3.2.5. Link Management Support 5.3.2.5. Link Management Support
Frame Delay defines a set of link management functions for PVC Status Frame Delay defines a set of link management functions for PVC Status
Management as specified in [T1.617D] and [Q.933A]. Link Management Management as specified in [T1.617D] and [Q.933A]. Link Management
runs on a dedicated PVC; therefore, its operation does not impact runs on a dedicated PVC; therefore, its operation does not impact
actual user data. The management functions include: actual user data. The management functions include:
- a heartbeat exchange that verifies that the link is operational - a heartbeat exchange that verifies that the link is operational
- a report regarding the status of one or more individual DLCIs - a report regarding the status of one or more individual DLCIs
For some networks, such as the one shown in Figure 11, this link For some networks, such as the one shown in Figure 15, this link
management is the only means to verify the end-to-end integrity of management is the only means to verify the end-to-end integrity of
the Frame Relay virtual circuit. The PWE may required to emulate the Frame Relay virtual circuit. The PE may required to emulate such
such functions. These functions will be transparent to the functions. These functions will be transparent to the underlying
underlying network. network.
Another important consideration is that there should be some Another important consideration is that there should be some
coordination between the PW's link status and the associated Frame coordination between the PW's link status and the associated Frame
Relay VCs. For example, it might be necessary to tear down the VCs Relay VCs. For example, it might be necessary to tear down the VCs
in the presence of a network fault. in the presence of a network fault.
5.3.2.6. DLCI Association 5.3.2.6. DLCI Association
There are two scopes of DLCI addressing that have been defined by There are two scopes of DLCI addressing that have been defined by
ANSI and ITU-T: Local and Global DLCIs. ANSI and ITU-T: Local and Global DLCIs.
- Local DLCI addressing means that DLCI numbers are only significant - Local DLCI addressing means that DLCI numbers are only significant
at one end of a Frame Relay virtual circuit at the local interface. at one end of a Frame Relay virtual circuit.
- Global DLCI addressing is an extension to PVC status management - Global DLCI addressing is an extension to PVC status management
that allows a DLCI number to have universal significance. A global that allows a DLCI number to have universal significance. A global
DLCI identifies the same VC at both ends across the network. DLCI identifies the same VC at both ends of the network.
In the case when the DLCI is locally significant, the management of In the case when the DLCI is locally significant, the management of
the PWD must provide a mechanism to coordinate the DLCIs at the two the PWD must provide a mechanism to coordinate the DLCIs at the two
ends of the PW. The association can be done via signaling or ends of the PW. The association can be done via signaling or
configuration. configuration.
5.3.2.7. Multiplexing VCs over PWs 5.3.2.7. Multiplexing VCs over PWs
To preserve PW tunnel space and to enhance scalability of PWs, it To preserve PW tunnel space and to enhance scalability of PWs, it
would be very valuable to allow one or more VCs to be multiplexed would be very valuable to allow one or more VCs to be multiplexed
onto the same PW. One scenario might be to associate an entire Frame onto the same PW. One scenario might be to associate an entire Frame
Relay logical interface to a PW. Another possibility is that the Relay logical interface to a PW. Another possibility is that the
assignment of VCs to the PW could be done via signaling or assignment of VCs to the PW could be done via signaling or
management. management. In either of these cases, the DLCI for each frame would
need to be preserved across the PW.
If such multiplexing approach is used, the earlier discussion related If such multiplexing approach is used, the earlier discussion related
to the packet sequencing, end-to-end transport characteristic, SLA to the packet sequencing, end-to-end characteristics, SLA
preservation and link status management, shall be addressed with the preservation and link status management, shall be addressed with the
same considerations. same considerations.
5.3.2.8. Signaling Transparency 5.3.2.8. Signaling Transparency
Since Frame Relay supports SVCs, the PWE may need to support Since Frame Relay supports SVCs, the PE may need to support signaling
signaling interworking at the service access for Frame Relay. interworking at the PWES. InverseARP frames should be passed on
InverseARP frames should be passed on without interpretation. In without interpretation. In either case, these frames shall be
either case, these frames shall be transparent to the underlying transparent to the underlying PSN.
transport.
5.3.2.9. Soft PVC Support 5.3.2.9. Soft PVC Support
One type of connection service that is provided by Frame Relay One type of connection service that is provided by Frame Relay
networks is called the Soft PVC (SPVC). The SPVC may be considered networks is called a Soft PVC (SPVC). A SPVC may be considered to be
as three parts: two peer-to-peer PVCs at each end of the edge, and a composed of three parts: two peer-to-peer PVCs at each side of the
SPVC between them. Figure 12 shows the SPVC interconnection example. core, and a SVC between them.
Figure 17 shows the SPVC interconnection example.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| E |========| C |:::::::| C |:::::::| C |======| E | | E |========| C |:::::::| C |:::::::| C |======| E |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Where: Where:
"E" is the edge switch "E" is the edge switch
"C" is the core switch "C" is the core switch
"=" is the permanent connection "=" is the permanent connection
":" is the switched connection ":" is the switched connection
Figure 12: Example of an SPVC Over a Frame Relay Network Figure 17: Example of an SPVC Over a Frame Relay Network
The creation of the SPVC within the core is triggered by detecting The creation of the SPVC within the core is triggered by detecting
the existence of the PVCs at the edges. This detection is done the existence of the PVCs at the edges. This detection is done
either by network management or by some proprietary signaling. either by network management or by some proprietary signaling.
Now consider the case where the Frame Relay Network is replaced by an Now consider the case where the core switches are replaced by PEs as
PW network as shown in the Figure 10. The SPVC connection within the shown in Figure 14. The SVC connection within the core is replaced
core is replaced by the PW. The behavior of the ingress and egress by the PW. The PVCs configuration which are maintained by the
edges of the IP core should still behave in the same way towards the ingress and the egress CEs of the PWD should remain the same. The
edge of the two Frame Relay switches at each end. ingress and egress PEs shall maintain the SPVC behavior such that it
is transparent to the CEs.
5.4. ATM 5.4. ATM
5.4.1. Reference Model 5.4.1. Reference Model
As far as PWs are concerned, ATM is very similar to Frame Relay. We As far as PWs are concerned, ATM is very similar to Frame Relay. We
will use the same reference network (Figure 9) for ATM as we did for will use the same reference network (Figure 13) for ATM as we did for
Frame Relay. Of course, the Frame Relay switches would be ATM Frame Relay. Of course, the Frame Relay switches would be ATM
switches instead. Likewise, the PWE networks shown in Figures 10 and switches instead. Likewise, the PE networks shown in Figures 14 and
11 are applicable to ATM. 15 are applicable to ATM.
5.4.2. Operational Considerations 5.4.2. Operational Considerations
Like Frame Relay, ATM provides connection-oriented circuit-based Like Frame Relay, ATM provides connection-oriented circuit-based
transport. There are two types of virtual circuit supported in ATM: carriage of fixed-size cells. There are two types of virtual circuit
PVC and SVC. In addition to virtual circuit connections (VCCs), ATM supported in ATM: PVC and SVC. In addition to virtual circuit
also supports virtual path connections (VPCs). There are also connections (VCCs), ATM also supports virtual path connections
permanent virtual paths (PVPs) and switched virtual paths (SVPs). (VPCs). There are also permanent virtual paths (PVPs) and switched
virtual paths (SVPs).
ATM transports data in fixed size (53 byte) frames called "cells". ATM carries data in fixed size (53 byte) frames called "cells".
Higher layer frames are adapted to these fixed size cells via ATM Higher layer frames are adapted to these fixed size cells via ATM
Adaptation Layers (e.g. AAL1, AAL2 and AAL5) and SAR. Different Adaptation Layers (e.g. AAL1, AAL2 and AAL5) and SAR. Different
types of AALs have different cell header formats, and the cells may types of AALs have different cell header formats, and the cells may
contain signaling information. contain signaling information.
The following sections describe the set of considerations for PW The following sections describe the set of considerations for PW
support of ATM. support of ATM.
5.4.2.1. Cell Sequence 5.4.2.1. Cell Sequence
The PW must deliver frames in the proper sequence. The PW must deliver cells in the proper sequence.
5.4.2.2. End-to-end Transport Characteristics 5.4.2.2. End-to-end Transport Characteristics
ITU-T [I.356] and ATM Forum [TM4.0] defines a set of traffic and QoS The ITU-T [I.356] and the ATM Forum [TM4.0] each define a set of
parameters. The design of the PW shall be capable of maintaining the traffic and QoS parameters. The AS for ATM PWs should specify how
end-to-end transport characteristic for such virtual circuit. the PW will maintain the end-to-end characteristics for such VCs.
5.4.2.3. ATM SLA 5.4.2.3. ATM SLA
ITU-T [I.371] defines performance targets for managing ATM traffic The ITU-T [I.371] defines performance targets for managing ATM
and congestion control. These target may be used by some service traffic and congestion control. These targets may be used by some
providers to define their ATM SLAs. The AS for ATM PWs should service providers to define their ATM SLAs. The AS for ATM PWs
specify how SLA transparency will be achieved. should specify how SLA transparency will be achieved.
5.4.2.4. Connection Management and Congestion Control 5.4.2.4. Connection Management and Congestion Control
The ATM header contains some connection management and congestion The ATM header contains some connection management and congestion
control information, as defined in [I.371]: control information, as defined in [I.371]:
- Cell Loss priority (CLP) - Cell Loss priority (CLP)
- Connection Identifier (VPI/VCI) - Connection Identifier (VPI/VCI)
- Payload Type Identifier (PTI) - distinguishes between an OAM - Payload Type Identifier (PTI) - distinguishes between an OAM
(Operations, Administration and Management) cell and a user cell (Operations, Administration and Management) cell and a user cell
- Explicit Forward Congestion Indication (EFCI) - Explicit Forward Congestion Indication (EFCI)
All of these fields are vital to the integrity of the ATM circuit. All of this information is vital to the integrity of the ATM circuit.
The ATM PW AS shall define an efficient but optimized approach to The ATM PW AS must define a means to preserve such information across
transport such information across the PWD. the PWD.
5.4.2.5. OAM and Link Management Support 5.4.2.5. OAM Support
ATM [I.610] defines a set of OAM functions. Likewise, [ILMI] defines ATM OAM functions are defined in the ITU-T standard [I.610]. OAM
a Link Management protocol to manage the ATM link, VCCs and VPCs. cells are used to provide functions like fault management,
ILMI Link Management runs on a dedicated PVC; its operation does not performance management and continuity checks.
impact actual user data. The management function is designed for a
"heartbeat" exchange that verifies that the link is operational. It
also provides a means to detect mis-configuration.
For some networks, such as the one shown in Figure 11, this link OAM is implemented differently in VCCs and VPCs. In the case of a
management is the only means to verify the end-to-end integrity of VCC, the OAM cell is sent along the same VC as the user cells. For a
the ATM virtual circuit. The PWE may required to emulate such VPC, the OAM cell is sent over a dedicated VC within the VPC. OAM
functions. These functions will be transparent to the underlying flows are also classified as end-to-end flows (covering the entire
network. virtual connection) or as segment flows (covering only parts of the
virtual connection).
OAM is often enabled to support important or real-time intensive The PE may emulate the end-to-end OAM flows by encapsulating the OAM
traffic. OAM operation differs between VCCs and VPCs. In the case cells in a PW-PDU. A PE that supports the OAM function should
of VCC, the OAM cell is sent along the same VC as the user cells. In support coordination between the OAM behavior between the PE peers.
the case of VPC, the OAM cell is sent over a dedicated VC within the For example, an OAM AIS cell at one end can result in PW signaling
VPC. that causes the PW link to go down at the far end. If the PE does
support OAM, the emulation of the OAM function shall be transparent
to the underlying network.
OAM emulation shall be limited at the edge of the PW only, and the 5.4.2.6. ILMI Support
entire operation shall be transparent within the core.
Another important consideration is that there should be some The Integrated Local Management Interface [ILMI] protocol facilitates
coordination between the PW's link status and the associated ATM VCs. network deployment and management in several ways:
For example, it might be necessary to tear down the ATM VCs in the
presence of a network fault.
5.4.2.6. VC Associations - ILMI allows an ATM node to determine the various features supported
by its neighbors (such as type of signaling, size of connection
space etc).
Each ATM connection ID has only local significance in the network. - ILMI allows for smoother administration of ATM addresses through
This local significance means that each ATM connection identifier address registration.
(VPI and/or VCI) is only significant at local ATM interface, and is
independent from the ID at the other end of the network. The
management of the PWD must provide a mechanism to coordinate the IDs
at the two ends of the PW. The association can be done via signaling
or configuration.
5.4.2.7. Multiplexing ATM VCs over PWs - ILMI facilitates automatic configuration of private interfaces.
- ILMI supports procedures for detecting loss of connectivity through
periodic polling.
For some networks, such as the one shown in Figure 15, ILMI is the
only means to verify the end-to-end integrity of the ATM virtual
circuit. It may be desirable for the PE to emulate such functions.
If supported, these functions must be transparent to the underlying
network.
5.4.2.7. VC Associations
Each ATM connection identifier has local significance only. Local
significance means that each ATM connection identifier (VPI and/or
VCI) is only significant at a local ATM interface, and is independent
from the identifier at the other end of the link. The management of
the PWD must provide a mechanism to coordinate the identifiers at the
two ends of the PW. The association can be done via signaling or
configuration.
5.4.2.8. Multiplexing ATM VCs over PWs
See the discussion in the "Multiplexing VCs over PWs" sub-section of See the discussion in the "Multiplexing VCs over PWs" sub-section of
the previous "Frame Relay" section of this document. the previous "Frame Relay" section of this document.
5.4.2.8. ATM Signaling Transparency 5.4.2.9. ATM Signaling Transparency
See the discussion in the "Signaling Transparency" sub-section of the See the discussion in the "Signaling Transparency" sub-section of the
previous "Frame Relay" section of this document. previous "Frame Relay" section of this document.
5.4.2.9. Soft PVC Support 5.4.2.10. Soft PVC Support
See the discussion and figures in the "Soft PVC Support" sub-section See the discussion and figures in the "Soft PVC Support" sub-section
of the previous "Frame Relay" section of this document. of the previous "Frame Relay" section of this document.
5.4.2.10. Segmentation and Reassembly (SAR) 5.4.2.11. Segmentation and Reassembly (SAR)
The bandwidth overhead of the ATM cell is about 10% (= 5 overhead The bandwidth overhead of the ATM cell is about 10% (= 5 overhead
bytes out of 53 bytes total). For AAL5 traffic [I.363.5], it may be bytes out of 53 bytes total). For AAL5 traffic [I.363.5], it may be
more efficient in terms of bandwidth to transport the re-assembled more efficient in terms of bandwidth to carry the re-assembled AAL5
AAL5 frames instead of the individual ATM cells. This would involve frames instead of the individual ATM cells. This would involve some
some cost in terms of a SAR operation at each end of the PW. In some cost in terms of a SAR operation at each end of the PW. In some
cases, especially if OAM is required to be supported over the PW, the cases, especially if OAM is required to be supported over the PW, the
PW may have no choice but to transport the ATM traffic in cell PW may have no choice but to transport the ATM traffic in cell
format. format.
Whether the ATM traffic is transported in a frame or cell format, it Whether the ATM traffic is transported in a frame or cell format, it
is the responsibility of the PWE to emulate the OAM functions to the is the responsibility of the PE to emulate the OAM functions to the
adjacent ATM interface at each end. adjacent ATM interface at each end.
6. Timing 6. PW Maintenance
In the recent Ken Burns Jazz television series, it was said of Louis 6.1. PW-PDU Validation
Armstrong that he was very economical with his notes, but that the
timing of those notes was everything. The timing of the
reconstructed bit stream is similarly important. This section
describes the various approaches to this problem. A summary is also
provided at the end of the section.
6.1. Reference Model It is a common practice to use a checksum, CRC or FCS to assure end-
to-end integrity of frames. The PW service-specific mechanisms must
define whether the packet's checksum shall be preserved across the
PWD or be removed at the ingress PE and then be re-calculated at the
egress PE. The former approach saves work, while the later saves
bandwidth.
Consider the example network shown in Figure 13. For protocols like ATM and Frame Relay, the checksum is only
applicable to a single link. This is because the circuit identifiers
(e.g. Frame Relay DLCI or ATM VPI/VCI) have only local significance
and are changed on each hop or span. If the circuit identifier (and
thus checksum) is going to change as a part of the PW emulation, it
would be more efficient to strip and re-calculate the checksum.
+----------+ +----------+ Other PDU headers (e.g. UDP in IP) do not change during transit. It
| PWE1 | | PWE2 | would make sense to preserve these types of checksums.
| | | |
+--+ | -----+ | +--+ +--+ | -----+ | +--+
|E1|=====>FIFO|:::::>|S1|::>|S2|:::::>FIFO|====>|E2|
+--+ | -----+ | +--+ +--+ | -----+ | +--+
| ^ ^ | | ^ ^ |
| | | |<-------+------>| | | |
| A B | | | C D |
+----------+ E +----------+
Where: The AS for each protocol must describe the validation scheme to be
"En" is the TDM edge device used.
"PWEn" is the PWE adaptation device
"Sn" is a core switch
"A" - "E" are clocks
"=" is the T1 Bit Stream
":" is the switched connection
Figure 13: Timing Recovery Reference Diagram 6.2. PW-PDU Sequencing
A jitter correction buffer at the receive can handle short-term One major consideration of PW design is to ensure in-sequence
differences between these two clocks, but over time any absolute delivery of packets, if needed. The design of the PW for each
difference is going to cause this buffer to overflow or underflow. protocol must consider the support of the PSN for in-order delivery
as well as the requirements of the particular application. For
example, MPLS supports connection-oriented transport with a guarantee
of in-order delivery. A sequence number in the PW layer is not
needed when used with MPLS. IP is connectionless and does not
guarantee in-order delivery. When using IP, a PW sequence number may
be needed for some applications (such as TDM).
Bits are clocked into a FIFO in PWE1 according to clock A, which is 6.3. Session Multiplexing
derived from the clock used at E1. The bits are packed into frames
and clocked out according to clock B, which is the same as clock B.
Clock B could differ from A, as long as there is an indication of the
number of bits contained in the PDU.
The frames arrive at switch S1, and are clocked out according to the One way to facilitate scaling is to increase the number of PWs per
internal oscillator on the output interface of switch S1. The frames underlying tunnel. There are two ways to achieve this:
will depart at the same average rate at which they arrived, but the
instantaneous bit rate will be different on each side of S1. Note
that there could be short-term variations due to congestion, but S1
can't experience long-term congestion with respect to the frames
carrying emulated data, or the service won't work.
The frames travel on to switch S2, which again forwards them. Note - For a service like Relay or ATM, all of the VCs on a given port
that switch S2 introduces yet another clock, which it uses to could be lumped together. VCs would not be distinguishable within
transmit the packets toward PWE2. Again the average rate is the PWD.
preserved, but the instantaneous rate will vary.
The frames arrive at PWE2 and are clocked into the FIFO when they - Service SDUs could be distinguished within a PW-PDU by port,
arrive (using clock C). Note that clock C will have the same average channel or VC identifiers. This approach would allow for switching
frequency as B, but will have short-term variations. The bits are or grooming in the PWD.
clocked out of the FIFO according to clock D.
6.2. Recreating the Timing 6.4. Security
The big question is: where does clock D in Figure 13 come from? Each AS must specify a means to protect the control of the PWE and
There are 5 possibilities, and these are detailed in the following the PE/PW signaling. The security-related protection of the
sections. encapsulated content of the PW is outside of scope.
1) Clock D is the same as clock A, and is delivered by clock E, which 6.5. Encapsulation Control
is an "External Timing" source, as described below.
2) If the switches S1 and S2 were synchronous, and SONET-style 6.5.1. Scalability
pointers were used, then Clock D could be derived from Clock C and
the pointers. This is described in the "SONET Pointer
Justification" section below.
3) Clock D is derived from the average rate of Clock C. This is the Different service types may be required between CEs, Support of
"Adaptive Timing" scenario described in a subsequent section. multiple services implies that a range of PWD label spaces may be
needed. If the PWD spans a PSN supporting traffic engineering, then
the ability to supporting label stacking would be desirable.
4) Clock D is derived from a combination of the local oscillator at 6.5.2. Service Integration
PWE2 and received RTP or SRTS timestamps. This is described in
the "RTP" and "Differential (SRTS)" sections below.
6.3. External Timing It may be desirable to design a PW to transport a variety of services
which have different transport characteristics. To achieve this
integration it may be useful to allow the service requirements to be
mapped to the tunneling label in such a way that the PWD can apply
the appropriate service and transport management to the PW.
The simplest method for communicating timing from one end of a system 6.6. Statistics
to the other is an external timing source. This external timing
source is normally a T1 or E1. Its 8 KHz frame rate is extracted and
used to directly clock the reconstructed data streams, or as an input
to a phase-locked loop to synthesize the desired clock. The drawback
to this method is that a common external clock is not commonly
available in a data network or in a multi-carrier network.
6.4. SONET Pointer Justification The PE can tabulate statistics that help monitor the state of the
network, and to help with measurement of SLAs. Typical counters
include:
SONET defines layers of pointers that allow for the multiplexing and - Counts of PW-PDUs sent and received, with and without errors.
transmission of asynchronous signals. These pointers convey the
timing of the carried signal with respect to the timing of the
encapsulating signal. Each SONET ADM must manipulate these pointers
to preserve the timing. This method has the advantage of being well-
defined and understood.
One way to apply this method to a packet-based network would be to - Counts of PW-PDUs lost (TDM only).
ensure that all of the links on a given path are synchronous. This
would be difficult for Gigabit Ethernet or POS links. Another way
would be for each router to update the pointers as the packet
traversed the router. This would be compute intensive. A final way
to use a pointer-based method would be to limit the path to one
physical hop.
6.5. Differential (SRTS) - Counts of service PDUs sent and received, with and without errors
(non-TDM).
[ATMCES] describes the SRTS (Synchronous Residual Time Stamp) method: - Service-specific interface counts.
The SRTS technique measures the Service Interface input These counters would be contained in a MIB, they should not replicate
clock frequency against a network-wide synchronization existing MIB counters.
signal that must be present in the IWF, and sends
difference signals, called Residual Time Stamps, in the
AAL1 header to the reassembly IWF. At the output IWF, the
differences can be combined with the network-wide
synchronization signal to re-create the input Service
Interface clock.
The requirement for a network-wide signal is reasonable in a Telco or 6.7. Traceroute
SONET environment, where such clocks are commonly available. From an
equipment implementation standpoint, this method is similar to the
SONET pointer method, which also uses adjustments that are relative
to a separate clock (the line rate in the case of SONET). The
advantage of a SRTS approach is from a deployment standpoint. A
reference clock must be available at both ends, but not at any of the
intervening routers.
6.6. Adaptive Timing Tracing functionality is desirable for emulated circuits and
services, because it allows verification and remediation of the
operation and configuration of the forwarding plane. [BONICA]
describes the requirements for a generic route tracing application.
Applicability of these requirements to PWE3 is an interesting
problem, as many of the emulated services have no equivalent
function. In general, there is not a way to trace the forwarding
plane of an TDM or Frame Relay PVC. ATM does provide an option in
the loopback OAM cell to return each intermediate hop (see [I.610]).
Adaptive timing is used when an external reference is not available. There needs to be a mechanism through which upper layers can ask
[ATMCES] describes adaptive timing as follows: emulated services to reveal their internal forwarding details. A
common mechanism for all emulated services over a particular PSN may
be possible. For example, if MPLS is the PSN, the path for a VC LSP
could be revealed via the signaling from the underlying TE tunnel
LSP, or perhaps via the proposed MPLS OAM. However, when we are
trying to trace the entire emulated service, starting from the CE
(e.g. an ATM VCC), then a uniform approach probably will not work and
different approaches would be required for different emulated
services.
The adaptive technique does not require a network-wide 6.8. Congestion Considerations
synchronization signal to regenerate the input Service
clock at the output IWF. A variety of techniques could be
used to implement Adaptive clock recovery. For example,
the depth of the reassembly buffer in the output IWF could
be monitored:
1. When the buffer depth is too great or tends to increase [RFC2914] describes how devices connected to the Internet should
with time, the frequency of the Service clock could be handle congestion. The discussion of congestion with respect to PWE3
increased to cause the buffer to drain more quickly. will be broken into two sections: CBR applications and VBR
applications.
2. When the buffer contains fewer than the configured 6.8.1. VBR Applications
number of bits, the Service clock could be slowed to
cause the buffer to drain less quickly. Wander may be
introduced by the Adaptive clock recovery technique if
there is a low-frequency component to the Cell Delay
Variation inserted by the ATM network carrying cells
from the input to output IWF.
Careful design is required to make adaptive timing work VBR applications include Ethernet, Frame Relay, and ATM (other than
well. The instantaneous buffer depth must be filtered to AAL CES). During periods of congestion the PE may be able to take
extract the average frequency and to reject the jitter and action to communicate to the CE the need to slow down.
wander.
Adaptive timing is ideal for many network applications where there is 6.8.1.1. Frame Relay
no external timing reference available (needed for SRTS), and where
the packet rate is decoupled from the line rate (as in a routed
network).
6.7. RTP In the presence of congestion, the PE could perform several actions.
These are the same actions that a Frame Relay switch might take. If
available, a measure of the degree of congestion would be useful.
[RTP] uses an absolute timestamp to play out the bits at the same - While a service provide may define an SLA for a Frame Relay
rate that they were received and packetized. RTCP (RTP Control Service, Frame Relay itself does not have a guarantee of delivery.
Protocol) provides a means to synchronize the transmit and receive Given this fact, the PE could do nothing in the face of congestion.
clocks. The Frame Relay application at the CE would then have to detect
congestion and act appropriately.
6.7.1. RTP Timestamps - Frame Relay defines BECN as an indication to a Frame Relay device
that traffic that it sent is experiencing congestion. See Figure
16 for an example of how BECN is sent. For mild congestion, the PE
could send BECN back to the CE. The CE could then reduce the
amount of traffic being sent. It is worth nothing that many Frame
Relay devices ignore BECN.
Section 4 of [RTP] defines a timestamp that is either 32-bits or - The CE could also send FECN in the direction in which congestion is
64-bits in size: occurring. See Figure 16 for an example of how FECN is sent.
Wallclock time (absolute time) is represented using the - During congestion, the PE could discard all frames with DE set
timestamp format of the Network Time Protocol (NTP), which
is in seconds relative to 0h UTC on 1 January 1900 [NTP].
The full resolution NTP timestamp is a 64-bit unsigned
fixed-point number with the integer part in the first 32
bits and the fractional part in the last 32 bits. In some
fields where a more compact representation is appropriate,
only the middle 32 bits are used; that is, the low 16 bits
of the integer part and the high 16 bits of the fractional
part. The high 16 bits of the integer part must be
determined independently.
A 32-bit absolute time stamp with a 16-bit fractional part would give - If the PE was aware of the CIR for the VCs, it could drop any
a 15 us granularity (= 1/65535), which is too coarse for circuit traffic in excess of CIR.
emulation. This means that the 64-bit timestamp must be used, with a
granularity of 23 ns.
The transmit timestamps are created according to the internal - For severe congestion the PE could take the interface down. If the
oscillator at PWE1 and interpreted according to the internal PE was generating the PVC status signaling then these messages
oscillator at PWE2. These two oscillators will vary by some amount, could be used to convey the problem to the CE. This approach is
even if they are very accurate. The effects of this difference (or not elegant and may not work well with existing Frame Relay
drift) is considered in the next section. applications.
6.7.2. Analysis of Clock Drift 6.8.1.2. ATM
Since the two oscillators will vary or drift over time, the FIFO at ATM has a forward notification of congestion (EFCI), but unlike Frame
PWE2 will eventually overflow or underflow, unless this drift is Relay there is no backwards notification. This leaves the following
corrected. Figure 14 below shows why this must happen. choices of action. These are the same actions that an ATM switch
might take.
TDM Frame Boundaries | | | | | | | - Do nothing and let the ATM application at the CE handle the
PWE1 Wallclock 125 250 375 500 625 750 875 problem. This may work for some applications, but it will make it
PWE1 Timestamps 1 2 3 4 5 6 7 difficult for service providers to guarantee a high QoS on the VC.
PWE2 Wallclock 125 250 375 500 625 700 825 - If the PE was aware of the traffic parameters for the VCs, it could
PWE2 Offset 0 0 0 0 0 50 50 drop any traffic that was out of profile.
PWE2 Timestamps 1 2 3 4 5 6 7
RTCP Update 750
Figure 14: Clock Drift - For severe congestion the PE could take the interface down. This
In Figure 14, PWE1 has a clock that is running faster than PWE2. may be worse than doing nothing.
Note that this difference is exaggerated in the figure. PWE1 sends
out packets according to its clock, with timestamps also derived from
its clock. PWE2 uses its clock to decide the appropriate times to
remove bits from the FIFO. It is clear that packets will arrive
faster than they are being removed, and The FIFO at PWE2 will
eventually overflow.
6.7.3. RTCP/NTP as a Solution 6.8.1.3. Ethernet
One possible solution is to use NTP [NTP] or RTCP [RTP] to coordinate A PE providing a PW to an Ethernet CE could react to congestion in
the clocks at PWE1 and PWE2. This is shown in Figure 14 in the row one of the following ways.
marked "RTCP Update" where a value of 750 arrives at PWE2. This lets
PWE2 create an appropriate offset to correct its output timing.
NTP could also be used to ensure that clocks B and D were very close - A PE could use Ethernet flow control during congestion by sending a
in their absolute value. PAUSE frame as described in Annex 31B of [802.3].
6.8. Summary of Timing Recovery Methods - A PE could do nothing and let the Ethernet application at the CE
handle the problem.
Figure 15 below shows a summary of the methods for timing recovery. - For severe congestion the PE could take the interface down. This
may be worse than doing nothing.
+-----------------------------+------+-----+-----+----+-----+ 6.8.2. CBR Applications
| Method->| Ext. |SONET|SRTS |RTP/|Adap-|
|Parameter |Source| Ptr | |RTCP|tive |
+-----------------------------+------+-----+-----+----+-----+
|External timing required? | yes | no | yes | no | no |
+-----------------------------+------+-----+-----+----+-----+
|Per-hop manipulation? | no | yes | no | no | no |
+-----------------------------+------+-----+-----+----+-----+
|De-jitter buffer? | yes | yes | yes | yes| yes |
+-----------------------------+------+-----+-----+----+-----+
|Clock synthesis? | no | yes | yes | yes| yes |
+-----------------------------+------+-----+-----+----+-----+
|Suitable for circuit timing? | yes | yes | yes | yes| yes |
+-----------------------------+------+-----+-----+----+-----+
Figure 15: Summary of Timing Recovery Methods CBR applications include layer 1 applications such as emulated
7. Integrity TDM/SONET streams, as well as layer 2 applications such as ATM AAL1
CES. These applications present a constant load on the network at
all times. They cannot slow down; they are either running at full
speed, or they are impaired. If congestion causes an excessive
number of packets to be lost, the PE could take down the interface
and send AIS to the CE. There is probably not much point in doing
this if the PE is operating in an unstructured mode, as the framer in
the CE will probably declare a LOS condition anyway. A PE operating
in a structured (framed) mode would always send a clean frame pattern
to the CE, so it might be desirable to send AIS to notify the CE that
there are problems with the PW.
7.1. Validation 7. Packet Switched Networks
Editor's Note: this section will describe how the transported data is This section discusses various types of PSNs for providing the PW
verified. It will also discuss whether the native checksum or CRC transport. The areas of considerations are:
should be transported or stripped and regenerated. This section
needs more work.
7.2. Sequencing - Explicit Multi-protocol Encapsulation Identifier
Editor's Note: this section will discuss preservation of order. This - Transport Integrity
section needs more work.
8. Management - Traffic Engineering Ability
8.1. Session Multiplexing - Session Multiplexing
One way to facilitate scaling is to increase the number of PWs per - Flow and Congestion Control
underlying tunnel. There are two ways to achieve this:
- For a service like Relay or ATM, all of the VCs on a given port - Packet Ordering
could be lumped together. VCs would not be distinguishable within
the PWD.
- Service SDUs could be distinguished within a PW-PDU by port, - Tunnel Maintenance
channel or VC identifiers. This approach would allow for switching
or grooming in the PWD.
Editor's Note: This section needs more work. - Scalability
8.2. Signaling - Overhead
Editor's Note - this section will describe the signaling used to - QoS and Traffic Management
establish and destroy sessions, as well as any variable parameters
related to encapsulation or operation. This section needs more work.
8.3. Security 7.1. IP
Editor's Note: this section will discuss the security of signaling. Below is a description of the aspects of the Internet Protocol [IP].
Security of the transported data is out of scope. This section needs
more work.
8.4. Encapsulation Control Explicit MP Encap ID No support for a full range of multi-service
protocols e.g. there is no protocol type
assigned for ATM or MPLS.
Editor's Note - this section will describe the control of variables Transport Integrity IP has a checksum over the header but not
related to encapsulation. This section needs more work. over the payload.
8.5. Statistics Traffic Engineering The TOS bits may be used as DiffServ code
points.
The PWE can tabulate statistics that help monitor the state of the Session Multiplexing No support for session multiplexing.
network. Typical counters include:
- Counts of PW-PDUs sent and received, with and without errors. Packet Order No support for preservation of order.
- Counts of service PDUs sent and received, with and without errors Tunnel Maintenance Protocols such as L2TP may be used to
(non-TDM). establish tunnels using IP packets.
- Service-specific interface counts. Flow/Congestion Control No built-in flow control to manage
congestion. IP relies on the upper layer
protocol, e.g. TCP, to perform the
congestion management.
Editor's Note: This section needs more work. Scalability It would be hard to imagine a protocol more
scalable than IP.
8.6. Administrative Status Transport Overhead Minimum of 20-byte header.
Editor's Note: this section will describe the control of QoS/Traffic Management No built-in QoS and traffic management.
administrative status. This section needs more work. However, one can apply DiffServ to select a
per-hop behavior for a class of traffic.
8.7. Operational Status 7.2. L2TP
Editor's Note: this section will describe the monitoring of Layer 2 Tunneling (L2TP) [L2TP] provides a virtual extension of PPP
operational status. This section needs more work. across an IP PSN.
9. Transport Protocols Explicit MP Encap ID Supports any routed protocol, e.g. IP, IPX
and AppleTalk that is supported by PPP.
9.1. IP Transport Integrity Support a checksum for the entire
encapsulated frame.
Editor's Note: This section describes any protocol-specific Traffic Engineering No companion traffic engineering mechanism
considerations for transport over IP. This section needs more work. to support L2TP tunnel establishment.
9.2. L2TP Session Multiplexing Supports two levels of session multiplexing
via the use of the "tunnel-id" and "session-
id" fields.
Editor's Note: This section describes any protocol-specific Packet Order By supporting the optional sequence number,
considerations for transport over L2TP. This section needs more packet re-ordering can be done at the PWE
work.
9.3. MPLS Tunnel Maintenance L2TP uses control messages to establish,
terminate and monitor the status of the
logical PPP sessions. These are independent
of the data messages. L2TP also provides an
optional keep-alive mechanism to detect non-
operational tunnel.
Editor's Note: This section describes any protocol-specific Flow/Congestion Control L2TP defines flow and congestion control
considerations for transport over MPLS. This section needs more mechanisms for the control traffic only; no
work. control for the data traffic. Even so, the
PE could apply value-added functions such as
admission control, policing and shaping of
the L2TP tunnel at the aggregate flows
level, e.g. DiffServ-TE.
9.4. Common Infrastructure Scalability Lack of label stacking ability.
Editor's Note: This section describes the common framework used over Transport Overhead Minimum overhead is 44-byte (20-byte IP
the three transport protocols. This section needs more work. header + 12-byte UDP header + 8-byte minimum
L2TP header + 4-byte PPP header) to support
L2TP encapsulation
10. Acknowledgments QoS/Traffic Management No built-in QoS and traffic management.
However, one can apply IntServ or DiffServ
to select the preferred transport behavior
for the entire tunnel, i.e. one traffic
class per L2TP tunnel.
7.3. MPLS
Multi-protocol Label Switching [MPLS] is designed to combine Layer 2
switching and Layer 3 routing technology to provide efficient packet
processing and forwarding over a variety of link layer and transport
technologies e.g. ATM, Frame Relay and SONET.
Explicit MP Encap ID No defined standard to identify the
encapsulated multi-protocol PDU.
Transport Integrity No checksum support.
Traffic Engineering Designed with many signaling, routing and
traffic management extensions to support
traffic engineering.
Session Multiplexing Supports session multiplexing via the MPLS
label and the EXP field.
Packet Order Connection-oriented transport with
guaranteed in-sequence delivery.
Tunnel Maintenance MPLS signaling provides the ability to
establish, terminate and monitor the status
of the LSP.
Flow and Congestion Control
MPLS-TE assumes external admission control,
policy and shaping mechanism to provide flow
and congestion control at the aggregate
traffic level.
Scalability Label stacking facilitates scalability.
Transport Overhead Minimum overhead is 4-byte + any MPLS
extension to support multi-protocol
encapsulation and transport.
QoS/Traffic Management MPLS-TE supports QoS and traffic management.
8. Acknowledgments
This document was created by the PWE3 Framework design team. This document was created by the PWE3 Framework design team.
11. References 9. References
11.1. IETF RFCs 9.1. IETF RFCs
[L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. [L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G.
Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC
2661, August 1999. 2661, August 1999.
[RTP] H. Schulzrinne et al, "RTP: A Transport Protocol for Real- [RTP] H. Schulzrinne et al, "RTP: A Transport Protocol for Real-
Time Applications", RFC1889, January 1996. Time Applications", RFC1889, January 1996.
[NTP] D. Mills, "Network Time Protocol Version 3", RFC1305, March [NTP] D. Mills, "Network Time Protocol Version 3", RFC1305, March
1992. 1992.
11.2. IETF Drafts [MPLS] E. Rosen, "Multiprotocol Label Switching Architecture",
RFC3031, January 2001.
[IP] DARPA, "Internet Protocol", RFC791, September 1981.
9.2. IETF Drafts
[ANAVI] Anavi et al, "TDM over IP" draft-anavi-tdmoip-01.txt, work [ANAVI] Anavi et al, "TDM over IP" draft-anavi-tdmoip-01.txt, work
in progress, February 2001. in progress, February 2001.
[MALIS] Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS [MALIS] Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS
(CEM) Encapsulation" (draft-malis-sonet-ces-mpls-03.txt), (CEM) Encapsulation" (draft-malis-sonet-ces-mpls-03.txt),
work in progress, February 2001. work in progress, February 2001.
[XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation Edge-to- [XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation Edge-to-
Edge (PWE3)" (draft-xiao-pwe3-requirements-00.txt), work in Edge (PWE3)" (draft-pwe3-requirements-01.txt), work in
progress, July 2001.
[MARTINI] Martini et al, "Transport of Layer 2 Frames Over MPLS"
(draft-martini-l2circuit-trans-mpls-06.txt), work in
progress, May 2001. progress, May 2001.
11.3. ATM Forum [BONICA] Bonica et al, "Tracing Requirements for Generic Tunnels"
(draft-bonica-tunneltrace-01.txt), work in progress,
February 2001.
[CALLON] Callon et al, "A Framework for Provider Provisioned Virtual
Private Networks" (draft-ietf-ppvpn-framework-00.txt), work
in progress, February 2001.
9.3. ATM Forum
[ATMCES] ATM Forum, "Circuit Emulation Service Interoperability [ATMCES] ATM Forum, "Circuit Emulation Service Interoperability
Specification Version 2.0" (af-vtoa-0078-000), January 1997. Specification Version 2.0" (af-vtoa-0078-000), January 1997.
[TM4.0] ATM Forum, "Traffic Management Specification Version 4.0", [TM4.0] ATM Forum, "Traffic Management Specification Version 4.0",
(af-tm-0056.000), April, 1996. (af-tm-0056.000), April, 1996.
[ILMI] ATM Forum, "Integrated Local Management Interface (ILMI) [ILMI] ATM Forum, "Integrated Local Management Interface (ILMI)
Specification Version 4.0", (af-ilmi-0065.000), September, Specification Version 4.0", (af-ilmi-0065.000), September,
1996. 1996.
11.4. Frame Relay Forum 9.4. Frame Relay Forum
[FRF.1.2] D. Sinicrope, "PVC User-to-Network Interface (UNI) [FRF.1.2] D. Sinicrope, "PVC User-to-Network Interface (UNI)
Implementation Agreement", Frame Relay Forum FRF.1.2, July Implementation Agreement", Frame Relay Forum FRF.1.2, July
2000. 2000.
[FRF.5] O'Leary et al, "Frame Relay/ATM PVC Network Interworking [FRF.5] O'Leary et al, "Frame Relay/ATM PVC Network Interworking
Implementation Agreement", Frame Relay Forum FRF.5, December Implementation Agreement", Frame Relay Forum FRF.5, December
20, 1994. 20, 1994.
[FRF.13] K. Rehbehn, "Service Level Definitions Implementation [FRF.13] K. Rehbehn, "Service Level Definitions Implementation
Agreement", Frame Relay Forum FRF.13, August 4, 1998. Agreement", Frame Relay Forum FRF.13, August 4, 1998.
11.5. ITU 9.5. ITU
[Q.933A] ITU, "ISDN Signaling Specifications for Frame Mode Switched [Q.933A] ITU, "ISDN Signaling Specifications for Frame Mode Switched
and Permanent Virtual Connections Control and Status and Permanent Virtual Connections Control and Status
Monitoring" ITU Recommendation Q.933, Annex A, Geneva, 1995. Monitoring" ITU Recommendation Q.933, Annex A, Geneva, 1995.
[I.356] ITU, "B-ISDN ATM Layer Cell Transfer Performance", ITU [I.356] ITU, "B-ISDN ATM Layer Cell Transfer Performance", ITU
Recommendation I.356, To Be Published. Recommendation I.356, To Be Published.
[I.363.1] ITU, "B-ISDN ATM Adaptation Layer specification: Type 1 [I.363.1] ITU, "B-ISDN ATM Adaptation Layer specification: Type 1
AAL", Recommendation I.363.1, August, 1996. AAL", Recommendation I.363.1, August, 1996.
skipping to change at page 41, line 29 skipping to change at page 45, line 5
[I.363.5] ITU, "B-ISDN ATM Adaptation Layer specification: Type 5 [I.363.5] ITU, "B-ISDN ATM Adaptation Layer specification: Type 5
AAL", Recommendation I.363.5, August, 1996. AAL", Recommendation I.363.5, August, 1996.
[I.371] ITU, "Traffic Control and Congestion Control in B-ISDN" ITU [I.371] ITU, "Traffic Control and Congestion Control in B-ISDN" ITU
Recommendation I.371, To Be Published. Recommendation I.371, To Be Published.
[I.610] ITU, "B-ISDN Operation and Maintenance Principles and [I.610] ITU, "B-ISDN Operation and Maintenance Principles and
Functions", ITU Recommendation I.610, February, 1999. Functions", ITU Recommendation I.610, February, 1999.
11.6. IEEE [G.811] ITU, "Timing Characteristics of Primary Reference Clocks",
ITU Recommendation G.811, September 1997.
[G.823] "The Control of Jitter and Wander Within Digital Networks
Which Are Based on the 2048 kbit/s Hierarchy", ITU
Recommendation G.823, March 2000.
[G.824] "The Control of Jitter and Wander Within Digital Networks
Which Are Based on the 1544 kbit/s Hierarchy", ITU
Recommendation G.824, March 2000.
9.6. IEEE
[802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition), [802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition),
Information technology --Telecommunications and information Information technology --Telecommunications and information
exchange between systems --IEEE standard for local and exchange between systems --IEEE standard for local and
metropolitan area networks --Common specifications--Media metropolitan area networks --Common specifications--Media
access control (MAC) Bridges", June, 1998. access control (MAC) Bridges", June, 1998.
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 1998 .
[802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information [802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information
technology--Telecommunications and information exchange technology--Telecommunications and information exchange
between systems --Local and metropolitan area networks between systems --Local and metropolitan area networks
--Specific requirements --Part 3: Carrier Sense Multiple --Specific requirements --Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method and Access with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications", 2000. Physical Layer Specifications", 2000.
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 9.7. ANSI
Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 1998 .
[802.3ac] IEEE Standard 802.3ac, "Supplement to Carrier Sense Multiple
Access with Collision Detection (CSMA/CD)Access Method &
Physical Layer Specification. Frame Extension for Virtual
Bridged Local Area Networks (VLAN) Tagging on 802.3
Networks," 1998.
11.7. ANSI
[T1.403] ANSI, "Network and Customer Installation Interfaces - DS1 [T1.403] ANSI, "Network and Customer Installation Interfaces - DS1
Electrical Interfaces", T1.403-1999, May 24, 1999. Electrical Interfaces", T1.403-1999, May 24, 1999.
[T1.617D] ANSI, "Digital Subscriber System No. 1 DSS1 Signaling [T1.617D] ANSI, "Digital Subscriber System No. 1 DSS1 Signaling
Specification for Frame Relay Bearer Service", ANSI Specification for Frame Relay Bearer Service", ANSI
T1.617-1991 (R1997), Annex D. T1.617-1991 (R1997), Annex D.
11.8. Telcordia 9.8. Telcordia
[GR253] Telcordia, "Synchronous Optical Network (SONET) Transport [GR253] Telcordia, "Synchronous Optical Network (SONET) Transport
Systems: Common Generic Criteria" (GR253CORE), Issue 3, Systems: Common Generic Criteria" (GR253CORE), Issue 3,
September 2000. September 2000.
12. Security Considerations 10. Security Considerations
It may be desirable to define methods for ensuring security during It may be desirable to define methods for ensuring security during
exchange of encapsulation control information at an administrative exchange of encapsulation control information at an administrative
boundary of the transport network. boundary of the PSN.
13. Authors' Addresses 11. Authors' Addresses
Prayson Pate Prayson Pate
Overture Networks Overture Networks
P. O. Box 14864 P. O. Box 14864
RTP, NC, USA 27709 RTP, NC, USA 27709
Email: prayson.pate@overturenetworks.com Email: prayson.pate@overturenetworks.com
XiPeng Xiao XiPeng Xiao
Photuris, Inc. Photuris, Inc.
2025 Stierlin Court 2025 Stierlin Court
skipping to change at page 43, line 4 skipping to change at page 46, line 36
Level 3 Communications, LLC. Level 3 Communications, LLC.
1025 Eldorado Blvd. 1025 Eldorado Blvd.
Broomfield, CO, 80021 Broomfield, CO, 80021
e-mail: Craig.White@Level3.com e-mail: Craig.White@Level3.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
14. Full Copyright Section
Andrew G. Malis
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Email: Andy.Malis@vivacenetworks.com
Thomas K. Johnson
Litchfield Communications
76 Westbury Park Rd.
Watertown, CT 06795
Email: tom_johnson@litchfieldcomm.com
12. Full Copyright Section
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 288 change blocks. 
902 lines changed or deleted 1325 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/