summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5659.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5659.txt')
-rw-r--r--doc/rfc/rfc5659.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc5659.txt b/doc/rfc/rfc5659.txt
new file mode 100644
index 0000000..1569b8c
--- /dev/null
+++ b/doc/rfc/rfc5659.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group M. Bocci
+Request for Comments: 5659 Alcatel-Lucent
+Category: Informational S. Bryant
+ Cisco Systems
+ October 2009
+
+
+ An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge
+
+Abstract
+
+ This document describes an architecture for extending pseudowire
+ emulation across multiple packet switched network (PSN) segments.
+ Scenarios are discussed where each segment of a given edge-to-edge
+ emulated service spans a different provider's PSN, as are other
+ scenarios where the emulated service originates and terminates on the
+ same provider's PSN, but may pass through several PSN tunnel segments
+ in that PSN. It presents an architectural framework for such multi-
+ segment pseudowires, defines terminology, and specifies the various
+ protocol elements and their functions.
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright and License Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 1]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Motivation and Context .....................................3
+ 1.2. Non-Goals of This Document .................................6
+ 1.3. Terminology ................................................6
+ 2. Applicability ...................................................8
+ 3. Protocol Layering Model .........................................8
+ 3.1. Domain of MS-PW Solutions ..................................9
+ 3.2. Payload Types ..............................................9
+ 4. Multi-Segment Pseudowire Reference Model ........................9
+ 4.1. Intra-Provider Connectivity Architecture ..................11
+ 4.1.1. Intra-Provider Switching Using ACs .................11
+ 4.1.2. Intra-Provider Switching Using PWs .................11
+ 4.2. Inter-Provider Connectivity Architecture ..................11
+ 4.2.1. Inter-Provider Switching Using ACs .................12
+ 4.2.2. Inter-Provider Switching Using PWs .................12
+ 5. PE Reference Model .............................................13
+ 5.1. Pseudowire Pre-Processing .................................13
+ 5.1.1. Forwarding .........................................13
+ 5.1.2. Native Service Processing ..........................14
+ 6. Protocol Stack Reference Model .................................14
+ 7. Maintenance Reference Model ....................................15
+ 8. PW Demultiplexer Layer and PSN Requirements ....................16
+ 8.1. Multiplexing ..............................................16
+ 8.2. Fragmentation .............................................17
+ 9. Control Plane ..................................................17
+ 9.1. Setup and Placement of MS-PWs .............................17
+ 9.2. Pseudowire Up/Down Notification ...........................18
+ 9.3. Misconnection and Payload Type Mismatch ...................18
+ 10. Management and Monitoring .....................................18
+ 11. Congestion Considerations .....................................19
+ 12. Security Considerations .......................................20
+ 13. Acknowledgments ...............................................23
+ 14. References ....................................................23
+ 14.1. Normative References .....................................23
+ 14.2. Informative References ...................................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 2]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+1. Introduction
+
+ RFC 3985 [1] defines the architecture for pseudowires, where a
+ pseudowire (PW) both originates and terminates on the edge of the
+ same packet switched network (PSN). The PW label is unchanged
+ between the originating and terminating provider edges (PEs). This
+ is now known as a single-segment pseudowire (SS-PW).
+
+ This document extends the architecture in RFC 3985 to enable point-
+ to-point pseudowires to be extended through multiple PSN tunnels.
+ These are known as multi-segment pseudowires (MS-PWs). Use cases for
+ multi-segment pseudowires (MS-PWs), and the consequent requirements,
+ are defined in RFC 5254 [5].
+
+1.1. Motivation and Context
+
+ RFC 3985 addresses the case where a PW spans a single segment between
+ two PEs. Such PWs are termed single-segment pseudowires (SS-PWs) and
+ provide point-to-point connectivity between two edges of a provider
+ network. However, there is now a requirement to be able to construct
+ multi-segment pseudowires. These requirements are specified in RFC
+ 5254 [5] and address three main problems:
+
+ i. How to constrain the density of the mesh of PSN tunnels when the
+ number of PEs grows to many hundreds or thousands, while
+ minimizing the complexity of the PEs and P-routers.
+
+ ii. How to provide PWs across multiple PSN routing domains or areas
+ in the same provider.
+
+ iii. How to provide PWs across multiple provider domains and
+ different PSN types.
+
+ Consider a single PW domain, such as that shown in Figure 1. There
+ are 4 PEs, and PWs must be provided from any PE to any other PE.
+ PWs can be supported by establishing a full mesh of PSN tunnels
+ between the PEs, requiring a full mesh of LDP signaling adjacencies
+ between the PEs. PWs can therefore be established between any PE and
+ any other PE via a single, direct PSN tunnel that is switched only by
+ intermediate P-routers (not shown in the figure). In this case, each
+ PW is an SS-PW. A PE must terminate all the pseudowires that are
+ carried on the PSN tunnels that terminate on that PE, according to
+ the architecture of RFC 3985. This solution is adequate for small
+ numbers of PEs, but the number of PEs, PSN tunnels, and signaling
+ adjacencies will grow in proportion to the square of the number of
+ PEs.
+
+
+
+
+
+Bocci & Bryant Informational [Page 3]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ For reasons of economy, the edge PEs that terminate the attachment
+ circuits (ACs) are often small devices built to very low cost with
+ limited processing power. Consider an example where a particular PE,
+ residing at the edge of a provider network, terminates N PWs to/from
+ N different remote PEs. This needs N PW signaling adjacencies to be
+ set up and maintained. If the edge PE attaches to a single
+ intermediate PE that is able to switch the PW, that edge PE only
+ needs a single adjacency to signal and maintain all N PWs. The
+ intermediate switching PE (which is a larger device) needs M
+ signaling adjacencies, but statistically this is less than tN, where
+ t is the number of edge PEs that it is serving. Similarly, if the
+ PWs are running over TE PSN tunnels, there is a statistical reduction
+ in the number of TE PSN tunnels that need to be set up and maintained
+ between the various PEs.
+
+ One possible solution that is more efficient for large numbers of
+ PEs, in particular for the control plane, is therefore to support a
+ partial mesh of PSN tunnels between the PEs, as shown in Figure 1.
+ For example, consider a PW service whose endpoints are PE1 and PE4.
+ Pseudowires for this can take the path PE1->PE2->PE4 and, rather than
+ terminating at PE2, be switched between ingress and egress PSN
+ tunnels on that PE. This requires a capability in PE2 that can
+ concatenate PW segments PE1-PE2 to PW segments PE2-PE4. The end-to-
+ end PW is known as a multi-segment PW.
+
+ ,,..--..,,_
+ .-`` `'.,
+ +-----+` '+-----+
+ | PE1 |---------------------| PE2 |
+ | |---------------------| |
+ +-----+ PSN Tunnel +-----+
+ / || || \
+ / || || \
+ | || || |
+ | || PSN || |
+ | || || |
+ \ || || /
+ \ || || /
+ \|| ||/
+ +-----+ +-----+
+ | PE3 |---------------------| PE4 |
+ | |---------------------| |
+ +-----+`'.,_ ,.'` +-----+
+ `'''---''``
+
+ Figure 1: PWs Spanning a Single PSN with Partial Mesh of PSN Tunnels
+
+
+
+
+
+Bocci & Bryant Informational [Page 4]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ Figure 1 shows a simple, flat PSN topology. However, large provider
+ networks are typically not flat, consisting of many domains that are
+ connected together to provide edge-to-edge services. The elements in
+ each domain are specialized for a particular role, for example,
+ supporting different PSN types or using different routing protocols.
+
+ An example application is shown in Figure 2. Here, the provider's
+ network is divided into three domains: two access domains and the
+ core domain. The access domains represent the edge of the provider's
+ network at which services are delivered. In the access domain,
+ simplicity is required in order to minimize the cost of the network.
+ The core domain must support all of the aggregated services from the
+ access domains, and the design requirements here are for scalability,
+ performance, and information hiding (i.e., minimal state). The core
+ must not be exposed to the state associated with large numbers of
+ individual edge-to-edge flows. That is, the core must be simple and
+ fast.
+
+ In a traditional layer 2 network, the interconnection points between
+ the domains are where services in the access domains are aggregated
+ for transport across the core to other access domains. In an IP
+ network, the interconnection points could also represent interworking
+ points between different types of IP networks, e.g., those with MPLS
+ and those without, and points where network policies can be applied.
+
+ <-------- Edge to Edge Emulated Services ------->
+
+ ,' . ,-` `', ,' .
+ / \ .` `, / \
+ / \ / , / \
+ AC +----+ +----+ +----+ +----+ AC
+ ---| PE |-----| PE |---------------| PE |-------| PE |---
+ | 1 | | 2 | | 3 | | 4 |
+ +----+ +----+ +----+ +----+
+ \ / \ / \ /
+ \ / \ Core ` \ /
+ `, ` . ,` `, `
+ '-'` `., _.` '-'`
+ Access 1 `''-''` Access 2
+
+ Figure 2: Multi-Domain Network Model
+
+ A similar model can also be applied to inter-provider services, where
+ a single PW spans a number of separate provider networks in order to
+ connect ACs residing on PEs in disparate provider networks. In this
+ case, each provider will typically maintain their own PE at the
+ border of their network in order to apply policies such as security
+
+
+
+
+Bocci & Bryant Informational [Page 5]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ and Quality of Service (QoS) to PWs entering their network. Thus,
+ the connection between the domains will normally be a link between
+ two PEs on the border of each provider's network.
+
+ Consider the application of this model to PWs. PWs use tunneling
+ mechanisms such as MPLS to enable the underlying PSN to emulate
+ characteristics of the native service. One solution to the multi-
+ domain network model above is to extend PSN tunnels edge-to-edge
+ between all of the PEs in access domain 1 and all of the PEs in
+ access domain 2, but this requires a large number of PSN tunnels, as
+ described above, and also exposes the access and the core of the
+ network to undesirable complexity. An alternative is to constrain
+ the complexity to the network domain interconnection points (PE2 and
+ PE3 in the example above). Pseudowires between PE1 and PE4 would
+ then be switched between PSN tunnels at the interconnection points,
+ enabling PWs from many PEs in the access domains to be aggregated
+ across only a few PSN tunnels in the core of the network. PEs in the
+ access domains would only need to maintain direct signaling sessions
+ and PSN tunnels, with other PEs in their own domain, thus minimizing
+ complexity of the access domains.
+
+1.2. Non-Goals of This Document
+
+ The following are non-goals for this document:
+
+ o The on-the-wire specification of PW encapsulations.
+
+ o The detailed specification of mechanisms for establishing and
+ maintaining multi-segment pseudowires.
+
+1.3. Terminology
+
+ The terminology specified in RFC 3985 [1] and RFC 4026 [2] applies.
+ In addition, we define the following terms:
+
+ o PW Terminating Provider Edge (T-PE). A PE where the customer-
+ facing attachment circuits (ACs) are bound to a PW forwarder. A
+ terminating PE is present in the first and last segments of an MS-
+ PW. This incorporates the functionality of a PE as defined in RFC
+ 3985.
+
+ o Single-Segment Pseudowire (SS-PW). A PW set up directly between
+ two T-PE devices. The PW label is unchanged between the
+ originating and terminating T-PEs.
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 6]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ o Multi-Segment Pseudowire (MS-PW). A static or dynamically
+ configured set of two or more contiguous PW segments that behave
+ and function as a single point-to-point PW. Each end of an MS-PW,
+ by definition, terminates on a T-PE.
+
+ o PW Segment. A part of a single-segment or multi-segment PW, which
+ traverses one PSN tunnel in each direction between two PE devices,
+ T-PEs, and/or S-PEs (switching PE).
+
+ o PW Switching Provider Edge (S-PE). A PE capable of switching the
+ control and data planes of the preceding and succeeding PW segments
+ in an MS-PW. The S-PE terminates the PSN tunnels of the preceding
+ and succeeding segments of the MS-PW. It therefore includes a PW
+ switching point for an MS-PW. A PW switching point is never the
+ S-PE and the T-PE for the same MS-PW. A PW switching point runs
+ necessary protocols to set up and manage PW segments with other PW
+ switching points and terminating PEs. An S-PE can exist anywhere a
+ PW must be processed or policy applied. It is therefore not
+ limited to the edge of a provider network.
+
+ Note that it was originally anticipated that S-PEs would only be
+ deployed at the edge of a provider network where they would be used
+ to switch the PWs of different service providers. However, as the
+ design of MS-PW progressed, other applications for MS-PW were
+ recognized. By this time S-PE had become the accepted term for the
+ equipment, even though they were no longer universally deployed at
+ the provider edge.
+
+ o PW Switching. The process of switching the control and data planes
+ of the preceding and succeeding PW segments in a MS-PW.
+
+ o PW Switching Point. The reference point in an S-PE where the
+ switching takes place, e.g., where PW label swap is executed.
+
+ o Eligible S-PE or T-PE. An eligible S-PE or T-PE is a PE that meets
+ the security and privacy requirements of the MS-PW, according to
+ the network operator's policy.
+
+ o Trusted S-PE or T-PE. A trusted S-PE or T-PE is a PE that is
+ understood to be eligible by its next-hop S-PE or T-PE, while a
+ trust relationship exists between two S-PEs or T-PEs if they
+ mutually consider each other to be eligible.
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 7]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+2. Applicability
+
+ An MS-PW is a single PW that, for technical or administrative
+ reasons, is segmented into a number of concatenated hops. From the
+ perspective of a Layer 2 Virtual Private Network (L2VPN), an MS-PW is
+ indistinguishable from an SS-PW. Thus, the following are equivalent
+ from the perspective of the T-PE:
+
+ +----+ +----+
+ |TPE1+--------------------------------------------------+TPE2|
+ +----+ +----+
+
+ |<---------------------------PW----------------------------->|
+
+ +----+ +---+ +---+ +----+
+ |TPE1+--------------+SPE+-----------+SPE+---------------+TPE2|
+ +----+ +---+ +---+ +----+
+
+ Figure 3: MS-PW Equivalence
+
+ Although an MS-PW may require services such as node discovery and
+ path signaling to construct the PW, it should not be confused with an
+ L2VPN system, which also requires these services. A Virtual Private
+ Wire Service (VPWS) connects its endpoints via a set of PWs. MS-PW
+ is a mechanism that abstracts the construction of complex PWs from
+ the construction of a L2VPN. Thus, a T-PE might be an edge device
+ optimized for simplicity and an S-PE might be an aggregation device
+ designed to absorb the complexity of continuing the PW across the
+ core of one or more service provider networks to another T-PE located
+ at the edge of the network.
+
+ As well as supporting traditional L2VPNs, an MS-PW is applicable to
+ providing connectivity across a transport network based on packet
+ switching technology, e.g., the MPLS Transport Profile (MPLS-TP) [6],
+ [8]. Such a network uses pseudowires to support the transport and
+ aggregation of all services. This application requires deterministic
+ characteristics and behavior from the network. The operational
+ requirements of such networks may need pseudowire segments that can
+ be established and maintained in the absence of a control plane, and
+ may also need the operational independence of PW maintenance from the
+ underlying PSN.
+
+3. Protocol Layering Model
+
+ The protocol layering model specified in RFC 3985 applies to MS-PWs
+ with the following clarification: the pseudowires may be considered
+ to be a separate layer to the PSN tunnel. That is, although a PW
+ segment will follow the path of the PSN tunnel between S-PEs, the
+
+
+
+Bocci & Bryant Informational [Page 8]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ MS-PW is independent of the PSN tunnel routing, operations,
+ signaling, and maintenance. The design of PW routing domains should
+ not imply that the underlying PSN routing domains are the same.
+ However, MS-PWs will reuse the protocols of the PSN and may, if
+ applicable, use information that is extracted from the PSN, e.g.,
+ reachability.
+
+3.1. Domain of MS-PW Solutions
+
+ PWs provide the Encapsulation Layer, i.e., the method of carrying
+ various payload types, and the interface to the PW Demultiplexer
+ Layer. Other layers provide the following:
+
+ o PSN tunnel setup, maintenance, and routing
+
+ o T-PE discovery
+
+ Not all PEs may be capable of providing S-PE functionality.
+ Connectivity to the next-hop S-PE or T-PE must be provided by a PSN
+ tunnel, according to [1]. The selection of which set of S-PEs to use
+ to reach a given T-PE is considered to be within the scope of MS-PW
+ solutions.
+
+3.2. Payload Types
+
+ MS-PWs are applicable to all PW payload types. Encapsulations
+ defined for SS-PWs are also used for MS-PW without change. Where the
+ PSN types for each segment of an MS-PW are identical, the PW types of
+ each segment must also be identical. However, if different segments
+ run over different PSN types, the encapsulation may change but the PW
+ segments must be of an equivalent PW type, i.e., the S-PE must not
+ need to process the PW payload to provide translation.
+
+4. Multi-Segment Pseudowire Reference Model
+
+ The pseudowire emulation edge-to-edge (PWE3) reference architecture
+ for the single-segment case is shown in [1]. This architecture
+ applies to the case where a PSN tunnel extends between two edges of a
+ single PSN domain to transport a PW with endpoints at these edges.
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 9]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ Native |<------Multi-Segment Pseudowire------>| Native
+ Service | PSN PSN | Service
+ (AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
+ | V V 1 V V 2 V V |
+ | +----+ +-----+ +----+ |
+ +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
+ | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| |
+ | CE1| | | | | | | | | |CE2 |
+ | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| |
+ +----+ | | |===========| |==========| | | +----+
+ ^ +----+ +-----+ +----+ ^
+ | Provider Edge 1 ^ Provider Edge 2 |
+ | | |
+ | | |
+ | PW switching point |
+ | |
+ |<------------------ Emulated Service --------------->|
+
+ Figure 4: MS-PW Reference Model
+
+ Figure 4 extends this architecture to show a multi-segment case. The
+ PEs that provide services to CE1 and CE2 are Terminating PE1 (T-PE1)
+ and Terminating PE2 (T-PE2), respectively. A PSN tunnel extends from
+ T-PE1 to Switching PE1 (S-PE1) across PSN1, and a second PSN tunnel
+ extends from S-PE1 to T-PE2 across PSN2. PWs are used to connect the
+ attachment circuits (ACs) attached to PE1 to the corresponding ACs
+ attached to T-PE2.
+
+ Each PW segment on the tunnel across PSN1 is switched to a PW segment
+ in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW
+ (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching
+ point. PW segment 1 and PW segment 3 are segments of the same MS-PW,
+ while PW segment 2 and PW segment 4 are segments of another MS-PW.
+ PW segments of the same MS-PW (e.g., PW segment 1 and PW segment 3)
+ must be of equivalent PW types, as described in Section 3.2, while
+ PSN tunnels (e.g., PSN1 and PSN2) may be of the same or different PSN
+ types. An S-PE switches an MS-PW from one segment to another based
+ on the PW demultiplexer, i.e., a PW label that may take one of the
+ forms defined in Section 5.4.1 of RFC 3985 [1].
+
+ Note that although Figure 4 only shows a single S-PE, a PW may
+ transit more than one S-PE along its path. This architecture is
+ applicable when the S-PEs are statically chosen, or when they are
+ chosen using a dynamic path-selection mechanism. Both directions of
+ an MS-PW must traverse the same set of S-PEs on a reciprocal path.
+ Note that although the S-PE path is therefore reciprocal, the path
+ taken by the PSN tunnels between the T-PEs and S-PEs might not be
+ reciprocal due to choices made by the PSN routing protocol.
+
+
+
+Bocci & Bryant Informational [Page 10]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+4.1. Intra-Provider Connectivity Architecture
+
+ There is a requirement to deploy PWs edge-to-edge in large service
+ provider networks (RFC 5254 [5]). Such networks typically encompass
+ hundreds or thousands of aggregation devices at the edge, each of
+ which would be a PE. These networks may be partitioned into separate
+ metro and core PW domains, where the PEs are interconnected by a
+ sparse mesh of tunnels.
+
+ Whether or not the network is partitioned into separate PW domains,
+ there is also a requirement to support a partial mesh of traffic-
+ engineered PSN tunnels.
+
+ The architecture shown in Figure 4 can be used to support such cases.
+ PSN1 and PSN2 may be in different administrative domains or access
+ regions, core regions, or metro regions within the same provider's
+ network. PSN1 and PSN2 may also be of different types. For example,
+ S-PEs may be used to connect PW segments traversing metro networks of
+ one technology, e.g., statically allocated labels, with segments
+ traversing an MPLS core network.
+
+ Alternatively, T-PE1, S-PE1, and T-PE2 may reside at the edges of the
+ same PSN.
+
+4.1.1. Intra-Provider Switching Using ACs
+
+ In this model, the PW reverts to the native service AC at the domain
+ boundary PE. This AC is then connected to a separate PW on the same
+ PE. In this case, the reference models of RFC 3985 apply to each
+ segment and to the PEs. The remaining PE architectural
+ considerations in this document do not apply to this case.
+
+4.1.2. Intra-Provider Switching Using PWs
+
+ In this model, PW segments are switched between PSN tunnels that span
+ portions of a provider's network, without reverting to the native
+ service at the boundary. For example, in Figure 4, PSN1 and PSN2
+ would be portions of the same provider's network.
+
+4.2. Inter-Provider Connectivity Architecture
+
+ Inter-provider PWs may need to be switched between PSN tunnels at the
+ provider boundary in order to minimize the number of tunnels required
+ to provide PW-based services to CEs attached to each provider's
+ network. In addition, the following may need to be implemented on a
+ per-PW basis at the provider boundary:
+
+
+
+
+
+Bocci & Bryant Informational [Page 11]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ o Operations, Administration, and Maintenance (OAM). Note that
+ this is synonymous with 'Operations and Maintenance' referred to
+ in RFC 5254 [5].
+
+ o Authentication, Authorization, and Accounting (AAA)
+
+ o Security mechanisms
+
+ Further security-related architectural considerations are described
+ in Section 12.
+
+4.2.1. Inter-Provider Switching Using ACs
+
+ In this model, the PW reverts to the native service at the provider
+ boundary PE. This AC is then connected to a separate PW at the peer
+ provider boundary PE. In this case, the reference models of RFC 3985
+ apply to each segment and to the PEs. This is similar to the case in
+ Section 4.1.1, except that additional security and policy enforcement
+ measures will be required. The remaining PE architectural
+ considerations in this document do not apply to this case.
+
+4.2.2. Inter-Provider Switching Using PWs
+
+ In this model, PW segments are switched between PSN tunnels in each
+ provider's network, without reverting to the native service at the
+ boundary. This architecture is shown in Figure 5. Here, S-PE1 and
+ S-PE2 are provider border routers. PW segment 1 is switched to PW
+ segment 2 at S-PE1. PW segment 2 is then carried across an inter-
+ provider PSN tunnel to S-PE2, where it is switched to PW segment 3 in
+ PSN2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 12]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ |<------Multi-Segment Pseudowire------>|
+ | Provider Provider |
+ AC | |<----1---->| |<----2--->| | AC
+ | V V V V V V |
+ | +----+ +-----+ +----+ +----+ |
+ +----+ | | |=====| |=====| |=====| | | +----+
+ | |-------|......PW.....X....PW.....X...PW.......|-------| |
+ | CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2 |
+ +----+ | | |=====| |=====| |=====| | | +----+
+ ^ +----+ +-----+ +----+ +----+ ^
+ | T-PE1 S-PE1 S-PE2 T-PE2 |
+ | ^ ^ |
+ | | | |
+ | PW switching points |
+ | |
+ | |
+ |<------------------- Emulated Service --------------->|
+
+ Figure 5: Inter-Provider Reference Model
+
+5. PE Reference Model
+
+5.1. Pseudowire Pre-Processing
+
+ Pseudowire pre-processing is applied in the T-PEs as specified in RFC
+ 3985. Processing at the S-PEs is specified in the following
+ sections.
+
+5.1.1. Forwarding
+
+ Each forwarder in the S-PE forwards packets from one PW segment on
+ the ingress PSN-facing interface of the S-PE to one PW segment on the
+ egress PSN-facing interface of the S-PE.
+
+ The forwarder selects the egress segment PW based on the ingress PW
+ label. The mapping of ingress to egress PW label may be statically
+ or dynamically configured. Figure 6 shows how a single forwarder is
+ associated with each PW segment at the S-PE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 13]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ +------------------------------------------+
+ | S-PE Device |
+ +------------------------------------------+
+ Ingress | | | | Egress
+ PW instance | Single | | Single | PW Instance
+ <==========>X PW Instance + Forwarder + PW Instance X<==========>
+ | | | |
+ +------------------------------------------+
+
+ Figure 6: Point-to-Point Service
+
+ Other mappings of PW-to-forwarder are for further study.
+
+5.1.2. Native Service Processing
+
+ There is no native service processing in the S-PEs.
+
+6. Protocol Stack Reference Model
+
+ Figure 7 illustrates the protocol stack reference model for multi-
+ segment PWs.
+
+ +-----------+ +-----------+
+ | Emulated | | Emulated |
+ | Service | | Service |
+ |(e.g., ATM)|<======= Emulated Service =======>|(e.g., ATM)|
+ +-----------+ +-----------+
+ | Payload | | Payload |
+ | Encap. |<=== Multi-segment Pseudowire ===>| Encap. |
+ +-----------+ +--------+ +-----------+
+ | PW Demux |<PW Segment>|PW Demux|<PW Segment>| PW Demux |
+ +-----------+ +--------+ +-----------+
+ |PSN Tunnel,|<PSN Tunnel>| PSN |<PSN Tunnel>|PSN Tunnel,|
+ | PSN & PHY | |Physical| | PSN & PHY |
+ | Layers | | Layers | | Layers |
+ +----+------+ +--------+ +-----+-----+
+ | .......... | .......... |
+ | / \ | / \ |
+ +==========/ PSN \===/ PSN \======+
+ \ domain 1 / \ domain 2 /
+ \__________/ \__________/
+ `````````` ``````````
+
+ Figure 7: Multi-Segment PW Protocol Stack
+
+ The MS-PW provides the CE with an emulated physical or virtual
+ connection to its peer at the far end. Native service PDUs from the
+ CE are passed through an Encapsulation Layer and a PW demultiplexer
+
+
+
+Bocci & Bryant Informational [Page 14]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ is added at the sending T-PE. The PDU is sent over PSN domain via
+ the PSN transport tunnel. The receiving S-PE swaps the existing PW
+ demultiplexer for the demultiplexer of the next segment and then
+ sends the PDU over transport tunnel in PSN2. Where the ingress and
+ egress PSN domains of the S-PE are of the same type, e.g., they are
+ both MPLS PSNs, a simple label swap operation is performed, as
+ described in Section 3.13 of RFC 3031 [3]. However, where the
+ ingress and egress PSNs are of different types, e.g., MPLS and
+ L2TPv3, the ingress PW demultiplexer is removed (or popped), and a
+ mapping to the egress PW demultiplexer is performed and then inserted
+ (or pushed).
+
+ Policies may also be applied to the PW at this point. Examples of
+ such policies include admission control, rate control, QoS mappings,
+ and security. The receiving T-PE removes the PW demultiplexer and
+ restores the payload to its native format for transmission to the
+ destination CE.
+
+ Where the encapsulation format is different, e.g., MPLS and L2TPv3,
+ the payload encapsulation may be translated at the S-PE.
+
+7. Maintenance Reference Model
+
+ Figure 8 shows the maintenance reference model for multi-segment
+ pseudowires.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 15]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ |<------------- CE (end-to-end) Signaling ------------>|
+ | |
+ | |<-------- MS-PW/T-PE Maintenance ----->| |
+ | | |<---PW Seg't-->| |<--PW Seg't--->| | |
+ | | | Maintenance | | Maintenance | | |
+ | | | | | | | |
+ | | | PSN | | PSN | | |
+ | | | |<-Tunnel1->| | | |<-Tunnel2->| | | |
+ | V V V Signaling V V V V Signaling V V V |
+ V +----+ +-----+ +----+ V
+ +----+ |TPE1|===========|SPE1 |===========|TPE2| +----+
+ | |-------|......PW.Seg't1....X....PW Seg't3......|------| |
+ | CE1| | | | | | | |CE2 |
+ | |-------|......PW.Seg't2....X....PW Seg't4......|------| |
+ +----+ | |===========| |===========| | +----+
+ ^ +----+ +-----+ +----+ ^
+ | Terminating ^ Terminating |
+ | Provider Edge 1 | Provider Edge 2 |
+ | | |
+ | PW switching point |
+ | |
+ |<--------------------- Emulated Service ------------------->|
+
+ Figure 8: MS-PW Maintenance Reference Model
+
+ RFC 3985 specifies the use of CE (end-to-end) and PSN tunnel
+ signaling as well as PW/PE maintenance. CE and PSN tunnel signaling
+ is as specified in RFC 3985. However, in the case of MS-PWs,
+ signaling between the PEs now has both an edge-to-edge and a hop-by-
+ hop context. That is, signaling and maintenance between T-PEs and
+ S-PEs and between adjacent S-PEs is used to set up, maintain, and
+ tear down the MS-PW segments, which includes the coordination of
+ parameters related to each switching point as well as to the MS-PW
+ endpoints.
+
+8. PW Demultiplexer Layer and PSN Requirements
+
+8.1. Multiplexing
+
+ The purpose of the PW Demultiplexer Layer at the S-PE is to
+ demultiplex PWs from ingress PSN tunnels and to multiplex them into
+ egress PSN tunnels. Although each PW may contain multiple native
+ service circuits, e.g., multiple ATM virtual circuits (VCs), the
+ S-PEs do not have visibility of, and hence do not change, this level
+ of multiplexing because they contain no Native Service Processor
+ (NSP).
+
+
+
+
+
+Bocci & Bryant Informational [Page 16]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+8.2. Fragmentation
+
+ If fragmentation is to be used in an MS-PW, T-PEs and S-PEs must
+ satisfy themselves that fragmented PW payloads can be correctly
+ reassembled for delivery to the destination attachment circuit.
+
+ An S-PE is not required to make any attempt to reassemble a
+ fragmented PW payload. However, it may choose to do so if, for
+ example, it knows that a downstream PW segment does not support
+ reassembly.
+
+ An S-PE may fragment a PW payload using [4].
+
+9. Control Plane
+
+9.1. Setup and Placement of MS-PWs
+
+ For multi-segment pseudowires, the intermediate PW switching points
+ may be statically provisioned or chosen dynamically.
+
+ For the static case, there are two options for exchanging the PW
+ labels:
+
+ o By configuration at the T-PEs or S-PEs.
+
+ o By signaling across each segment using a dynamic maintenance
+ protocol.
+
+ A multi-segment pseudowire may thus consist of segments where the
+ labels are statically configured and segments where the labels are
+ signaled.
+
+ For the case of dynamic choice of the PW switching points, there are
+ two options for selecting the path of the MS-PW:
+
+ o T-PEs determine the full path of the PW through intermediate
+ switching points. This may be either static or based on a dynamic
+ PW path-selection mechanism.
+
+ o Each T-PE and S-PE makes a local decision as to which next-hop S-PE
+ to choose to reach the target T-PE. This choice is made either
+ using locally configured information or by using a dynamic PW
+ path-selection mechanism.
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 17]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+9.2. Pseudowire Up/Down Notification
+
+ Since a multi-segment PW consists of a number of concatenated PW
+ segments, the emulated service can only be considered as being up
+ when all of the constituting PW segments and PSN tunnels are
+ functional and operational along the entire path of the MS-PW.
+
+ If a native service requires bi-directional connectivity, the
+ corresponding emulated service can only be signaled as being up when
+ the PW segments and PSN tunnels (if used), are functional and
+ operational in both directions.
+
+ RFC 3985 describes the architecture of failure and other status
+ notification mechanisms for PWs. These mechanisms are also needed in
+ multi-segment pseudowires. In addition, if a failure notification
+ mechanism is provided for consecutive segments of the same PW, the
+ S-PE must propagate such notifications between the consecutive
+ concatenated segments.
+
+9.3. Misconnection and Payload Type Mismatch
+
+ Misconnection and payload type mismatch can occur with PWs.
+ Misconnection can breach the integrity of the system. Payload
+ mismatch can disrupt the customer network. In both instances, there
+ are security and operational concerns.
+
+ The services of the underlying tunneling mechanism or the PW control
+ and OAM protocols can be used to ensure that the identity of the PW
+ next hop is as expected. As part of the PW setup, a PW-TYPE
+ identifier is exchanged. This is then used by the forwarder and the
+ NSP of the T-PEs to verify the compatibility of the ACs. This can
+ also be used by S-PEs to ensure that concatenated segments of a given
+ MS-PW are compatible or that an MS-PW is not misconnected into a
+ local AC. In addition, it is possible to perform an end-to-end
+ connection verification to check the integrity of the PW, to verify
+ the identity of S-PEs and check the correct connectivity at S-PEs,
+ and to verify the identity of the T-PE.
+
+10. Management and Monitoring
+
+ The management and monitoring as described in RFC 3985 applies here.
+
+ The MS-PW architecture introduces additional considerations related
+ to management and monitoring, which need to be reflected in the
+ design of maintenance tools and additional management objects for
+ MS-PWs.
+
+
+
+
+
+Bocci & Bryant Informational [Page 18]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ The first is that each S-PE is a new point at which defects may occur
+ along the path of the PW. In order to troubleshoot MS-PWs,
+ management and monitoring should be able to operate on a subset of
+ the segments of an MS-PW, as well as edge-to-edge. That is,
+ connectivity verification mechanisms should be able to troubleshoot
+ and differentiate the connectivity between T-PEs and intermediate
+ S-PEs, as well as the connectivity between T-PE and T-PE.
+
+ The second is that the set of S-PEs and P-routers along the MS-PW
+ path may be less optimal than a path between the T-PEs chosen solely
+ by the underlying PSN routing protocols. This is because the S-PEs
+ are chosen by the MS-PW path selection mechanism and not by the PSN
+ routing protocols. Troubleshooting mechanisms should therefore be
+ provided to verify the set of S-PEs that are traversed by an MS-PW to
+ reach a T-PE.
+
+ Some of the S-PEs and the T-PEs for an MS-PW may reside in a
+ different service provider's PSN domain from that of the operator who
+ initiated the establishment of the MS-PW. These situations may
+ necessitate the use of remote management of the MS-PW, which is able
+ to securely operate across provider boundaries.
+
+11. Congestion Considerations
+
+ The following congestion considerations apply to MS-PWs. These are
+ in addition to the considerations for PWs described in RFC 3985 [1],
+ [7], and the respective RFCs specifying each PW type.
+
+ The control plane and the data plane fate-share in traditional IP
+ networks. The implication of this is that congestion in the data
+ plane can cause degradation of the operation of the control plane.
+ Under quiescent operating conditions, it is expected that the network
+ will be designed to avoid such problems. However, MS-PW mechanisms
+ should also consider what happens when congestion does occur, when
+ the network is stretched beyond its design limits, for example,
+ during unexpected network failure conditions.
+
+ Although congestion within a single provider's network can be
+ mitigated by suitable engineering of the network so that the traffic
+ imposed by PWs can never cause congestion in the underlying PSN, a
+ significant number of MS-PWs are expected to be deployed for inter-
+ provider services. In this case, there may be no way of a provider
+ who initiates the establishment of an MS-PW at a T-PE guaranteeing
+ that it will not cause congestion in a downstream PSN. A specific
+ PSN may be able to protect itself from excess PW traffic by policing
+ all PWs at the S-PE at the provider border. However, this may not be
+
+
+
+
+
+Bocci & Bryant Informational [Page 19]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ effective when the PSN tunnel across a provider utilizes the transit
+ services of another provider that cannot distinguish PW traffic from
+ ordinary, TCP-controlled IP traffic.
+
+ Each segment of an MS-PW therefore needs to implement congestion
+ detection and congestion control mechanisms where it is not possible
+ to explicitly provision sufficient capacity to avoid congestion.
+
+ In many cases, only the T-PEs may have sufficient information about
+ each PW to fairly apply congestion control. Therefore, T-PEs need to
+ be aware of which of their PWs are causing congestion in a downstream
+ PSN and of their native service characteristics, and to apply
+ congestion control accordingly. S-PEs therefore need to propagate
+ PSN congestion state information between their downstream and
+ upstream directions. If the MS-PW transits many S-PEs, it may take
+ some time for congestion state information to propagate from the
+ congested PSN segment to the source T-PE, thus delaying the
+ application of congestion control. Congestion control in the S-PE at
+ the border of the congested PSN can enable a more rapid response and
+ thus potentially reduce the duration of congestion.
+
+ In addition to protecting the operation of the underlying PSN,
+ consistent QoS and traffic engineering mechanisms should be used on
+ each segment of an MS-PW to support the requirements of the emulated
+ service. The QoS treatment given to a PW packet at an S-PE may be
+ derived from context information of the PW (e.g., traffic or QoS
+ parameters signaled to the S-PE by an MS-PW control protocol) or from
+ PSN-specific QoS flags in the PSN tunnel label or PW demultiplexer,
+ e.g., TC bits in either the label switched path (LSP) or PW label for
+ an MPLS PSN or the DS field of the outer IP header for L2TPv3.
+
+12. Security Considerations
+
+ The security considerations described in RFC 3985 [1] apply here.
+ Detailed security requirements for MS-PWs are specified in RFC 5254
+ [5]. This section describes the architectural implications of those
+ requirements.
+
+ The security implications for T-PEs are similar to those for PEs in
+ single-segment pseudowires. However, S-PEs represent a point in the
+ network where the PW label is exposed to additional processing. An
+ S-PE or T-PE must trust that the context of the MS-PW is maintained
+ by a downstream S-PE. OAM tools must be able to verify the identity
+ of the far end T-PE to the satisfaction of the network operator.
+ Additional consideration needs to be given to the security of the
+ S-PEs, both at the data plane and the control plane, particularly
+ when these are dynamically selected and/or when the MS-PW transits
+ the networks of multiple operators.
+
+
+
+Bocci & Bryant Informational [Page 20]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ An implicit trust relationship exists between the initiator of an
+ MS-PW, the T-PEs, and the S-PEs along the MS-PW's path. That is, the
+ T-PE trusts the S-PEs to process and switch PWs without compromising
+ the security or privacy of the PW service. An S-PE should not select
+ a next-hop S-PE or T-PE unless it knows it would be considered
+ eligible, as defined in Section 1.3, by the originator of the MS-PW.
+ For dynamically placed MS-PWs, this can be achieved by allowing the
+ T-PE to explicitly specify the path of the MS-PW. When the MS-PW is
+ dynamically created by the use of a signaling protocol, an S-PE or
+ T-PE should determine the authenticity of the peer entity from which
+ it receives the request and the compliance of that request with
+ policy.
+
+ Where an MS-PW crosses a border between one provider and another
+ provider, the MS-PW segment endpoints (S-PEs or T-PEs) or, for the
+ PSN tunnel, P-routers typically reside on the same nodes as the
+ Autonomous System Border Router (ASBRs) interconnecting the two
+ providers. In either case, an S-PE in one provider is connected to a
+ limited number of trusted T-PEs or S-PEs in the other provider. The
+ number of such trusted T-PEs or S-PEs is bounded and not anticipated
+ to create a scaling issue for the control plane authentication
+ mechanisms.
+
+ Directly interconnecting the S-PEs/T-PEs using a physically secure
+ link and enabling signaling and routing authentication between the
+ S-PEs/T-PEs eliminates the possibility of receiving an MS-PW
+ signaling message or packet from an untrusted peer. The S-PEs/T-PEs
+ represent security policy enforcement points for the MS-PW, while the
+ ASBRs represent security policy enforcement points for the provider's
+ PSNs. This architecture is illustrated in Figure 9.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 21]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ |<------------- MS-PW ---------------->|
+ | Provider Provider |
+ AC | |<----1---->| |<----2--->| | AC
+ | V V V V V V |
+ | +----+ +-----+ +----+ +----+ |
+ +---+ | | |=====| |=====| |=====| | | +---+
+ | |-------|......PW.....X....PW.....X...PW.......|-------| |
+ |CE1| | | |Seg 1| |Seg 2| |Seg 3| | | |CE2|
+ +---+ | | |=====| |=====| |=====| | | +---+
+ ^ +----+ +-----+ ^ +----+ +----+ ^
+ | T-PE1 S-PE1 | S-PE2 T-PE2 |
+ | ASBR | ASBR |
+ | | |
+ | Physically secure link |
+ | |
+ | |
+ |<------------------- Emulated Service --------------->|
+
+ Figure 9: Directly Connected Inter-Provider Reference Model
+
+ Alternatively, the P-routers for the PSN tunnel may reside on the
+ ASBRs, while the S-PEs or T-PEs reside behind the ASBRs within each
+ provider's network. A limited number of trusted inter-provider PSN
+ tunnels interconnect the provider networks. This is illustrated in
+ Figure 10.
+
+ |<-------------- MS-PW -------------------->|
+ | Provider Provider |
+ AC | |<------1----->| |<-----2------->| | AC
+ | V V V V V V |
+ | +---+ +---+ +--+ +--+ +---+ +---+ |
+ +---+ | | |=====| |===============| |=====| | | +---+
+ | |-----|.....PW....X.......PW..............PW....X.|------| |
+ |CE1| | | |Seg 1| | Seg 2 | |Seg 3| | | |CE2|
+ +---+ | | |=====| |===============| |=====| | | +---+
+ ^ +---+ +---+ +--+ ^ +--+ +---+ +---+ ^
+ | T-PE1 S-PE1 ASBR | ASBR S-PE2 T-PE2 |
+ | | |
+ | | |
+ | Trusted Inter-AS PSN Tunnel |
+ | |
+ | |
+ |<------------------- Emulated Service ----------------->|
+
+ Figure 10: Indirectly Connected Inter-Provider Reference Model
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 22]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ Particular consideration needs to be given to Quality of Service
+ requests because the inappropriate use of priority may impact any
+ service guarantees given to other PWs. Consideration also needs to
+ be given to the avoidance of spoofing the PW demultiplexer.
+
+ Where an S-PE provides interconnection between different providers,
+ security considerations that are similar to the security
+ considerations for ASBRs apply. In particular, peer entity
+ authentication should be used.
+
+ Where an S-PE also supports T-PE functionality, mechanisms should be
+ provided to ensure that MS-PWs are switched correctly to the
+ appropriate outgoing PW segment, rather than to a local AC. Other
+ mechanisms for PW endpoint verification may also be used to confirm
+ the correct PW connection prior to enabling the attachment circuits.
+
+13. Acknowledgments
+
+ The authors gratefully acknowledge the input of Mustapha Aissaoui,
+ Dimitri Papadimitrou, Sasha Vainshtein, and Luca Martini.
+
+14. References
+
+14.1. Normative References
+
+ [1] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-
+ to-Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+ [2] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
+ Private Network (VPN) Terminology", RFC 4026, March 2005.
+
+ [3] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
+ Switching Architecture", RFC 3031, January 2001.
+
+ [4] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge
+ (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
+
+14.2. Informative References
+
+ [5] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
+ "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge
+ (PWE3)", RFC 5254, October 2008.
+
+ [6] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport
+ Profile", RFC 5654, September 2009.
+
+
+
+
+
+Bocci & Bryant Informational [Page 23]
+
+RFC 5659 Multi-Segment PWE3 Architecture October 2009
+
+
+ [7] Bryant, S., Davie, B., Martini, L., and E. Rosen, "Pseudowire
+ Congestion Control Framework", Work in Progress, June 2009.
+
+ [8] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
+ Transport Networks", Work in Progress, August 2009.
+
+Authors' Addresses
+
+ Matthew Bocci
+ Alcatel-Lucent
+ Voyager Place, Shoppenhangers Road,
+ Maidenhead, Berks, UK
+ Phone: +44 1633 413600
+ EMail: matthew.bocci@alcatel-lucent.com
+
+
+ Stewart Bryant
+ Cisco Systems
+ 250, Longwater,
+ Green Park,
+ Reading, RG2 6GB,
+ United Kingdom
+ EMail: stbryant@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci & Bryant Informational [Page 24]
+