< draft-ietf-pwe3-framework-00.txt		draft-ietf-pwe3-framework-01.txt >
	Internet Draft Prayson Pate, Editor		Internet Draft Prayson Pate, Editor
	Document: draft-ietf-pwe3-framework-00.txt Overture Networks, Inc.		Document: draft-ietf-pwe3-framework-01.txt Overture Networks, Inc.
	XiPeng Xiao		XiPeng Xiao
	Photuris Inc.		Redback Networks
	Craig White Tricci So		Craig White Tricci So
	Level 3 Communications, LLC. Caspian Networks		Level 3 Communications, LLC. Caspian Networks
	Kireeti Kompella Andrew G. Malis		Kireeti Kompella Andrew G. Malis
	Juniper Networks, Inc. Vivace Networks		Juniper Networks, Inc. Vivace Networks
	Thomas K. Johnson Thomas D. Nadeau		Thomas K. Johnson Thomas D. Nadeau
	Litchfield Communications Stewart Bryant		Litchfield Communications Stewart Bryant
	Cisco Systems		Cisco Systems
	Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)		Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)
	draft-ietf-pwe3-framework-00.txt		draft-ietf-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 Wire Emulation		This document describes a framework for Pseudo Wire Emulation
	Edge-to-Edge (PWE3). It discusses the emulation of circuits (such as		Edge-to-Edge (PWE3). It discusses the emulation of services (such
	T1, E1, T3, E3 and SONET/SDH) and services (such as ATM and Frame		Frame Relay, ATM, Ethernet T1, E1, T3, E3 and SONET/SDH) over packet
	Relay) over packet switched networks (PSNs) using IP or MPLS. It		switched networks (PSNs) using IP or MPLS. It presents an
	presents an architectural framework for pseudo wires (PWs), defines		architectural framework for pseudo wires (PWs), defines terminology,
	terminology, specifies the various protocol elements and their		specifies the various protocol elements and their functions,
	functions, overviews some of the services that will be supported and		overviews some of the services that will be supported and discusses
	discusses how PWs fit into the broader context of protocols.		how PWs fit into the broader context of protocols.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Table of Contents		Table of Contents
	1 Introduction ................................................. 3		1 Introduction ................................................. 3
	1.1 What Are Pseudo Wires? .................................... 3		1.1 What Are Pseudo Wires? .................................... 3
	1.2 Goals of This Document ..................................... 4		1.2 Goals of This Document ..................................... 4
	1.3 Non-Goals .................................................. 4		1.3 Non-Goals .................................................. 4
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	4.9 PW SNMP MIB Architecture ................................... 19		4.9 PW SNMP MIB Architecture ................................... 19
	5 Acknowledgments .............................................. 21		5 Acknowledgments .............................................. 21
	6 References ................................................... 21		6 References ................................................... 21
	7 Security Considerations ...................................... 23		7 Security Considerations ...................................... 23
	8 IANA Considerations .......................................... 23		8 IANA Considerations .......................................... 23
	9 Authors' Addresses ........................................... 23		9 Authors' Addresses ........................................... 23
	10 Full Copyright Section ...................................... 24		10 Full Copyright Section ...................................... 24
	1. Introduction		1. Introduction
	This document describes a framework for Pseudo Wire Emulation		This document describes a framework for Pseudo Wire Emulation
	Edge-to-Edge (PWE3). It discusses the emulation of circuits (such as		Edge-to-Edge (PWE3). It discusses the emulation of services (such
	T1, E1, T3, E3 and SONET/SDH) and services (such as ATM and Frame		Frame Relay, ATM, Ethernet T1, E1, T3, E3 and SONET/SDH) over packet
	Relay) over packet switched networks (PSNs) using IP or MPLS. It		switched networks (PSNs) using IP or MPLS. It presents an
	presents an architectural framework for pseudo wires (PWs), defines		architectural framework for pseudo wires (PWs), defines terminology,
	terminology, specifies the various protocol elements and their		specifies the various protocol elements and their functions,
	functions, overviews the services supported and discusses how PWs fit		overviews the services supported and discusses how PWs fit into the
	into the broader context of protocols. See [XIAO] for the		broader context of protocols. See [XIAO] for the requirements for
	requirements for PWs.		PWs.
	1.1. What Are Pseudo Wires?		1.1. What Are Pseudo Wires?
	1.1.1. Definition		1.1.1. Definition
	PWE3 is a mechanism that emulates the essential attributes of a		PWE3 is a mechanism that emulates the essential attributes of a
	service (such as a T1 leased line or Frame Relay) over a PSN. The		service (such as a T1 leased line or Frame Relay) over a PSN. The
	required functions of PWs include encapsulating service-specific		required functions of PWs include encapsulating service-specific
	bit-streams or PDUs arriving at an ingress port, and carrying them		bit-streams or PDUs arriving at an ingress port, and carrying them
	across a path or tunnel, managing their timing and order, and any		across a path or tunnel, managing their timing and order, and any
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	- 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 non-goals for this document:		The following are non-goals for this document:
	- The detailed specification of the bits and bytes of the		- The detailed specification of the bits and bytes of the
	encapsulations of the various services. This description is		encapsulations of the various services. This description is
	contained in an EEMD and/or ES.		contained in an EEMD and/or AS.
	- The detailed definition of the protocols involved in PW setup and		- The detailed definition of the protocols involved in PW setup and
	maintenance.		maintenance.
	The following are outside the scope of PWE3:		The following are outside the scope of PWE3:
	- Discussion of the protection of the encapsulated content of the PW.		- Discussion of 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,
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 43 ¶
	(AS) that describes the applicability of PWs for		(AS) that describes the applicability of PWs for
	that service.		that service.
	Encapsulation, Emulation and Maintenance Documents		Encapsulation, Emulation and Maintenance Documents
	Each PW service will have an Encapsulation,		Each PW service will have an Encapsulation,
	Emulation and Maintenance Document (EEMDs) that		Emulation and Maintenance Document (EEMDs) that
	described the particulars of PWs for that service,		described the particulars of PWs for that service,
	as well as the degree of faithfulness to that		as well as the degree of faithfulness to that
	service.		service.
	Inbound The traffic direction where information from a CE is		PSN Bound The traffic direction where information from a CE is
	adapted to a PW, and PW-PDUs are sent into the PSN.		adapted to a PW, and PW-PDUs are sent into the PSN.
	Outbound The traffic direction where PW-PDUs are received on		CE Bound The traffic direction where PW-PDUs are received on
	a PW from the PSN, re-converted back in the emulated		a PW from the PSN, re-converted back in the emulated
	service, and sent out to a CE.		service, and sent out to a CE.
	CE Signaling CE (end-to-end) Signaling refers to messages sent		CE Signaling CE (end-to-end) Signaling refers to messages sent
	and received by the CEs. It may be desirable or		and received by the CEs. It may be desirable or
	even necessary for the PE to participate in or		even necessary for the PE to participate in or
	monitor this signaling in order to effectively		monitor this signaling in order to effectively
	emulate the service.		emulate the service.
	PE/PW Maintenance		PE/PW Maintenance
	skipping to change at page 9, line 47 ¶		skipping to change at page 9, line 47 ¶
	How do service providers realize the capital and operational benefits		How do service providers realize the capital and operational benefits
	of a new packet-based infrastructure, while leveraging the existing		of a new packet-based infrastructure, while leveraging the existing
	base of SONET (Synchronous Optical Network) gear, and while also		base of SONET (Synchronous Optical Network) gear, and while also
	protecting the large revenue stream associated with this equipment?		protecting the large revenue stream associated with this equipment?
	How do they move from mature Frame Relay or ATM networks, while still		How do they move from mature Frame Relay or ATM networks, while still
	being able to provide these lucrative services?		being able to provide these lucrative services?
	One possibility is the emulation of circuits or services via PWs.		One possibility is the emulation of circuits or services via PWs.
	Circuit emulation over ATM and interworking of Frame Relay and ATM		Circuit emulation over ATM and interworking of Frame Relay and ATM
	have already been standardized. Emulation allows existing circuits		have already been standardized. Emulation allows existing services
	and/or services to be carried across the new infrastructure, and thus		to be carried across the new infrastructure, and thus enables the
	enables the interworking of disparate networks. [ATMCES] provides		interworking of disparate networks. [ATMCES] provides some insight
	some insight into the requirements for such a service:		into the requirements for 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 13, line 36 ¶		skipping to change at page 13, line 36 ¶
	| Physical |		| Physical |
	+---------------------------+		+---------------------------+
	Figure 4: Logical Protocol Layering Model		Figure 4: Logical Protocol Layering Model
	The logical protocol-layering model shown in Figure 4 above minimizes		The logical protocol-layering model shown in Figure 4 above minimizes
	the differences between the PWs operating over different PSN types.		the differences between the PWs operating over different PSN types.
	The payload is transported over the Encapsulation Layer that carries		The payload is transported over the Encapsulation Layer that carries
	any information that is not available in the payload itself and which		any information that is not available in the payload itself and which
	is needed by the PW outbound interface to send the reconstructed		is needed by the CE Bound interface to send the reconstructed service
	service to the CE. If needed, this layer also provides support for		to the CE. If needed, this layer also provides support for real-time
	real-time processing, sequencing and indication of length.		processing, sequencing and indication of length.
	The Multiplexing Layer provides the ability to deliver multiple PWs		The Multiplexing Layer provides the ability to deliver multiple PWs
	over a single PSN tunnel.		over a single PSN tunnel.
	The PSN header, MAC/datalink and physical layer definitions are		The PSN header, MAC/datalink and physical layer definitions are
	outside the scope of this framework.		outside the scope of this framework.
	3.5.2. Instantiation of the Protocol Layers		3.5.2. Instantiation of the Protocol Layers
	The instantiation of the logical protocol-layering model of Figure 4		The instantiation of the logical protocol-layering model of Figure 4
	skipping to change at page 16, line 10 ¶		skipping to change at page 16, line 10 ¶
	MPLS provides switching service, but no length or fragmentation		MPLS provides switching service, but no length or fragmentation
	service. When MPLS is used as the PSN, the encapsulation must provide		service. When MPLS is used as the PSN, the encapsulation must provide
	length and fragmentation services, if needed.		length and fragmentation services, if needed.
	3.6. Architecture Assumptions		3.6. 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 out of scope.		service interworking is out of scope.
	2) The initial design of PWE3 is focused on a single homogeneous		2) The initial design of PWE3 is focused on a single homogeneous
	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 PW types and the support of		Support for interworking between different PW types is for further
	inter-domain PWs are for further study.		study, as is the support of inter-domain PWs.
	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 will 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 EEMD and AS		service, as well as on the network implementation. An EEMD and AS
	shall be created for each service to describe the degree of		shall be created for each service to describe the degree of
	faithfulness of a PW to the native service.		faithfulness of 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. Support for the switched emulated circuit
	SVC/SVP) will be for further study.		type (e.g. SVC/SVP) is be for further study.
	5) The creation and placement of the PSN tunnel to support the PW is		5) The creation and placement of the PSN tunnel to support the PW is
	not 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 and MPLS. Other encapsulation approaches are for		on IPv4, IPv6 and MPLS. Support for other encapsulation
	further study.		approaches is for 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, 802.1Q), Frame Relay, ATM and TDM (e.g. DS1, DS3,		802.3ac VLAN, 802.1Q), Frame Relay, ATM and TDM (e.g. DS1, DS3,
	E1, SONET/SDH etc.).		E1, SONET/SDH etc.).
	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. The PW also inherits any security features		the emulated services. The PW also inherits any security features
	from the PSN e.g. IPsec for an IP PSN. No PW-specific security		from the PSN e.g. IPsec for an IP PSN. No PW-specific security
	skipping to change at page 17, line 23 ¶		skipping to change at page 17, line 23 ¶
	would make sense to preserve these types of checksums.		would make sense to preserve these types of checksums.
	The EEMD for each protocol must describe the validation scheme to be		The EEMD for each protocol must describe the validation scheme to be
	used.		used.
	4.2. PW-PDU Sequencing		4.2. PW-PDU Sequencing
	One major consideration of PW design is how to ensure in-sequence		One major consideration of PW design is how to ensure in-sequence
	delivery of packets, if needed. The design of the PW for each		delivery of packets, if needed. The design of the PW for each
	protocol must consider the support of the PSN for in-order delivery		protocol must consider the support of the PSN for in-order delivery
	as well as the requirements of the particular application. for		as well as the requirements of the particular application. For
	example, IP is connectionless and does not guarantee in-order		example, IP is connectionless and does not guarantee in-order
	delivery. When using IP, a PW sequence number may be needed for some		delivery. When using IP, a PW sequence number may be needed for some
	applications (such as TDM).		applications (such as TDM).
	4.3. Session Multiplexing		4.3. Session Multiplexing
	One way to facilitate scaling is to increase the number of PWs per		One way to facilitate scaling is to increase the number of PWs per
	underlying tunnel. There are two ways to achieve this:		underlying tunnel. There are two ways to achieve this:
	- For a service like Relay or ATM, all of the VCs on a given port		- For a service like Relay or ATM, all of the VCs on a given port
	skipping to change at page 18, line 28 ¶		skipping to change at page 18, line 28 ¶
	- Counts of PW-PDUs sent and received, with and without errors.		- Counts of PW-PDUs sent and received, with and without errors.
	- Counts of PW-PDUs lost (TDM only).		- Counts of PW-PDUs lost (TDM only).
	- Counts of service PDUs sent and received, with and without errors		- Counts of service PDUs sent and received, with and without errors
	(non-TDM).		(non-TDM).
	- Service-specific interface counts.		- Service-specific interface counts.
	These counters would be contained in a MIB, they should not replicate		These counters would be contained in a PW-specific MIB, and they
	existing MIB counters.		should not replicate existing MIB counters.
	4.7. Traceroute		4.7. Traceroute
	Tracing functionality is desirable for emulated circuits and		Tracing functionality is desirable for emulated services, because it
	services, because it allows verification and remediation of the		allows verification and remediation of the operation and
	operation and configuration of the forwarding plane. [BONICA]		configuration of the forwarding plane. [BONICA] describes the
	describes the requirements for a generic route tracing application.		requirements for a generic route tracing application. Applicability
	Applicability of these requirements to PWE3 is an interesting		of these requirements to PWE3 is an interesting problem, as many of
	problem, as many of the emulated services have no equivalent		the emulated services have no equivalent function. In general, there
	function. In general, there is not a way to trace the forwarding		is not a way to trace the forwarding plane of an TDM or Frame Relay
	plane of an TDM or Frame Relay PVC. ATM does provide an option in		PVC. ATM does provide an option in the loopback OAM cell to return
	the loopback OAM cell to return each intermediate hop (see [I.610]).		each intermediate hop (see [I.610]).
	There needs to be a mechanism through which upper layers can ask		There needs to be a mechanism through which upper layers can ask
	emulated services to reveal their internal forwarding details. A		emulated services to reveal their internal forwarding details. A
	common mechanism for all emulated services over a particular PSN may		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		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		could be revealed via the signaling from the underlying TE tunnel
	LSP, or perhaps via the proposed MPLS OAM. However, when we are		LSP, or perhaps via the proposed MPLS OAM. However, when we are
	trying to trace the entire emulated service, starting from the CE		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		(e.g. an ATM VCC), then a uniform approach probably will not work and
	different approaches would be required for different emulated		different approaches would be required for different emulated
	skipping to change at page 22, line 29 ¶		skipping to change at page 22, line 29 ¶
	[MALIS] Malis et al, "SONET/SDH Circuit Emulation over Packet (CEP)"		[MALIS] Malis et al, "SONET/SDH Circuit Emulation over Packet (CEP)"
	(draft-malis-pwe3-sonet-01.txt), work in progress, November		(draft-malis-pwe3-sonet-01.txt), work in progress, November
	2001.		2001.
	[XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation		[XIAO] Xiao et al, "Requirements for Pseudo Wire Emulation
	Edge-to-Edge (PWE3)" (draft-pwe3-requirements-02.txt), work		Edge-to-Edge (PWE3)" (draft-pwe3-requirements-02.txt), work
	in progress, November 2001.		in progress, November 2001.
	[BONICA] Bonica et al, "Tracing Requirements for Generic Tunnels"		[BONICA] Bonica et al, "Tracing Requirements for Generic Tunnels"
	(draft-bonica-tunneltrace-01.txt), work in progress,		(draft-bonica-tunneltrace-02.txt), work in progress,
	February 2001.		November 2001.
	[LAU] J Lau et al, Layer Two Tunneling Protocol "L2TP",		[LAU] J Lau et al, Layer Two Tunneling Protocol "L2TP",
	(draft-ietf-l2tpext-l2tp-base-01.txt) work in progress,		(draft-ietf-l2tpext-l2tp-base-02.txt) work in progress,
	October 2001.		March 2002.
	[PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information Base		[PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information Base
	Using SMIv2", (draft-zelig-pw-mib-00.txt), work in progress,		Using SMIv2", (draft-zelig-pw-mib-02.txt), work in progress,
	July 2001.		February 2002.
	[PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and		[PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and
	OBJECT-IDENTITIES for Pseudo-Wires Management"		OBJECT-IDENTITIES for Pseudo-Wires Management"
	(draft-nadeau-pw-tc-mib-00.txt), work in progress, July		(draft-nadeau-pw-tc-mib-02.txt), work in progress, February
	2001.		2002.
	[PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over		[PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over
	MPLS (CEM) Management Information Base Using SMIv2",		MPLS (CEM) Management Information Base Using SMIv2",
	(draft-danenberg-pw-cem-mib-00.txt), work in progress, July		(draft-danenberg-pw-cem-mib-01.txt), work in progress,
	2001.		November 2001.
	[LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management		[LSRMIB] Srinivasan et al, "MPLS Label Switch Router Management
	Information Base Using SMIv2",		Information Base Using SMIv2",
	draft-ietf-mpls-lsr-mib-07.txt, work in progress, January		draft-ietf-mpls-lsr-mib-08.txt, work in progress, January
	2001.		2002.
	[TEMIB] Srinivasan et al, "Traffic Engineering Management		[TEMIB] Srinivasan et al, "Traffic Engineering Management
	Information Base Using SMIv2",		Information Base Using SMIv2",
	<draft-ietf-mpls-te-mib-05.txt>, work in progress, November		<draft-ietf-mpls-te-mib-05.txt>, work in progress, January
	2000.		2002.
	[LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions		[LDP-MIB] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions
	of Managed Objects for the Multiprotocol Label Switching,		of Managed Objects for the Multiprotocol Label Switching,
	Label Distribution Protocol (LDP)",		Label Distribution Protocol (LDP)",
	<draft-ietf-mpls-ldp-mib-08.txt>, work in progress, August		<draft-ietf-mpls-ldp-mib-08.txt>, work in progress, August
	2001.		2001.
	[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.
	skipping to change at page 23, line 46 ¶		skipping to change at page 23, line 46 ¶
	exchange of encapsulation control information at an administrative		exchange of encapsulation control information at an administrative
	boundary of the PSN.		boundary of the PSN.
	8. IANA Considerations		8. IANA Considerations
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	9. Authors' Addresses		9. Authors' Addresses
	Prayson Pate XiPeng Xiao		Prayson Pate XiPeng Xiao
	Overture Networks, Inc. Photuris, Inc.		Overture Networks, Inc. Redback Networks
	P. O. Box 14864 2025 Stierlin Court		P. O. Box 14864 300 Holger Way
	RTP, NC, USA 27709 Mountain View, CA 94043		RTP, NC, USA 27709 San Jose, CA 95134
	prayson.pate@overturenetworks.com xiaoxipe@cse.msu.edu		prayson.pate@overturenetworks.com xipeng@redback.com
	Tricci So Craig White		Tricci So Craig White
	Caspian Networks Level 3 Communications, LLC.		Caspian Networks Level 3 Communications, LLC.
	170 Baytech Dr. 1025 Eldorado Blvd.		170 Baytech Dr. 1025 Eldorado Blvd.
	San Jose, CA 95134 Broomfield, CO, 80021		San Jose, CA 95134 Broomfield, CO, 80021
	tso@caspiannetworks.com Craig.White@Level3.com		tso@caspiannetworks.com Craig.White@Level3.com
	Kireeti Kompella Andrew G. Malis		Kireeti Kompella Andrew G. Malis
	Juniper Networks, Inc. Vivace Networks, Inc.		Juniper Networks, Inc. Vivace Networks, Inc.
	1194 N. Mathilda Ave. 2730 Orchard Parkway		1194 N. Mathilda Ave. 2730 Orchard Parkway
	Sunnyvale, CA 94089 San Jose, CA 95134		Sunnyvale, CA 94089 San Jose, CA 95134
End of changes. 25 change blocks.
	65 lines changed or deleted		65 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/