| < draft-ietf-pwe3-arch-06.txt | draft-ietf-pwe3-arch-07.txt > | |||
|---|---|---|---|---|
| Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant | Pseudo-Wire Edge-to-Edge (PWE3) Working Group Stewart Bryant | |||
| Internet Draft Cisco Systems | Internet Draft Cisco Systems | |||
| Document: <draft-ietf-pwe3-arch-06.txt> | Document: <draft-ietf-pwe3-arch-07.txt> | |||
| Expires: April 2004 Prayson Pate | Expires: September 2004 Prayson Pate | |||
| Overture Networks, Inc. | Overture Networks, Inc. | |||
| Editors | Editors | |||
| October 2003 | March 2003 | |||
| PWE3 Architecture | PWE3 Architecture | |||
| 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 RFC2026. | all provisions of section 10 of RFC2026. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
| skipping to change at page 2, line 19 ¶ | skipping to change at page 3, line 5 ¶ | |||
| Thomas K. Johnson Litchfield Communications | Thomas K. Johnson Litchfield Communications | |||
| Kireeti Kompella Juniper Networks, Inc. | Kireeti Kompella Juniper Networks, Inc. | |||
| Andrew G. Malis Tellabs | Andrew G. Malis Tellabs | |||
| Thomas D. Nadeau Cisco Systems | Thomas D. Nadeau Cisco Systems | |||
| Tricci So Caspian Networks | Tricci So Caspian Networks | |||
| W. Mark Townsley Cisco Systems | W. Mark Townsley Cisco Systems | |||
| Craig White Level 3 Communications, LLC. | Craig White Level 3 Communications, LLC. | |||
| Lloyd Wood Cisco Systems | Lloyd Wood Cisco Systems | |||
| XiPeng Xiao Riverstone Networks | XiPeng Xiao Riverstone Networks | |||
| Conventions used in this document | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
| document are to be interpreted as described in [RFC2119]. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction............................................. 5 | 1. Introduction............................................. 5 | |||
| 1.1 Pseudo Wire Definition............................... 5 | 1.1 Pseudo Wire Definition............................... 5 | |||
| 1.2 PW Service Functionality............................. 6 | 1.2 PW Service Functionality............................. 6 | |||
| 1.3 Non-Goals of this document........................... 6 | 1.3 Non-Goals of this document........................... 6 | |||
| 1.4 Terminology.......................................... 6 | 1.4 Terminology.......................................... 6 | |||
| 2. PWE3 Applicability....................................... 9 | 2. PWE3 Applicability....................................... 9 | |||
| skipping to change at page 3, line 34 ¶ | skipping to change at page 3, line 34 ¶ | |||
| 4.4 Protocol Stack Reference Model....................... 19 | 4.4 Protocol Stack Reference Model....................... 19 | |||
| 4.5 Pre-processing Extension to Protocol Stack Reference | 4.5 Pre-processing Extension to Protocol Stack Reference | |||
| Model................................................ 20 | Model................................................ 20 | |||
| 5. PW Encapsulation......................................... 21 | 5. PW Encapsulation......................................... 21 | |||
| 5.1 Payload Convergence Layer............................ 22 | 5.1 Payload Convergence Layer............................ 22 | |||
| 5.2 Payload-independent PW Encapsulation Layers.......... 24 | 5.2 Payload-independent PW Encapsulation Layers.......... 24 | |||
| 5.3 Fragmentation........................................ 27 | 5.3 Fragmentation........................................ 27 | |||
| 5.4 Instantiation of the Protocol Layers................. 27 | 5.4 Instantiation of the Protocol Layers................. 27 | |||
| 6. PW Demultiplexer Layer and PSN Requirements.............. 32 | 6. PW Demultiplexer Layer and PSN Requirements.............. 30 | |||
| 6.1 Multiplexing......................................... 32 | 6.1 Multiplexing......................................... 30 | |||
| 6.2 Fragmentation........................................ 33 | 6.2 Fragmentation........................................ 31 | |||
| 6.3 Length and Delivery.................................. 33 | 6.3 Length and Delivery.................................. 31 | |||
| 6.4 PW-PDU Validation.................................... 33 | 6.4 PW-PDU Validation.................................... 31 | |||
| 6.5 Congestion Considerations............................ 33 | 6.5 Congestion Considerations............................ 31 | |||
| 7. Control Plane............................................ 34 | 7. Control Plane............................................ 32 | |||
| 7.1 Set-up or Teardown of Pseudo-Wires................... 34 | 7.1 Set-up or Teardown of Pseudo-Wires................... 32 | |||
| 7.2 Status Monitoring.................................... 35 | 7.2 Status Monitoring.................................... 33 | |||
| 7.3 Notification of Pseudo-wire Status Changes........... 35 | 7.3 Notification of Pseudo-wire Status Changes........... 33 | |||
| 7.4 Keep-alive........................................... 37 | 7.4 Keep-alive........................................... 34 | |||
| 7.5 Handling Control Messages of the Native Services..... 37 | 7.5 Handling Control Messages of the Native Services..... 35 | |||
| 8. Management and Monitoring................................. 37 | 8. Management and Monitoring................................. 35 | |||
| 8.1 Status and Statistics................................ 37 | 8.1 Status and Statistics................................ 35 | |||
| 8.2 PW SNMP MIB Architecture............................. 38 | 8.2 PW SNMP MIB Architecture............................. 36 | |||
| 8.3 Connection Verification and Traceroute................ 41 | 8.3 Connection Verification and Traceroute................ 39 | |||
| 9. IANA considerations...................................... 41 | 9. IANA considerations...................................... 40 | |||
| 10. Security Considerations................................. 41 | 10. Security Considerations................................. 40 | |||
| 1. Introduction | 1. Introduction | |||
| This document describes an architecture for Pseudo Wire Emulation | This document describes an architecture for Pseudo Wire Emulation | |||
| Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation | Edge-to-Edge (PWE3) in support of [XIAO]. It discusses the emulation | |||
| of services (such as Frame Relay, ATM, Ethernet, TDM and SONET/SDH) | of services (such as Frame Relay, ATM, Ethernet, TDM and SONET/SDH) | |||
| over packet switched networks (PSNs) using IP or MPLS. It presents | over packet switched networks (PSNs) using IP or MPLS. It presents | |||
| the architectural framework for pseudo wires (PWs), defines | the architectural framework for pseudo wires (PWs), defines | |||
| terminology, specifies the various protocol elements and their | terminology, specifies the various protocol elements and their | |||
| functions. | functions. | |||
| skipping to change at page 5, line 43 ¶ | skipping to change at page 5, line 43 ¶ | |||
| required degree of faithfulness. | required degree of faithfulness. | |||
| From the perspective of a Customer Edge Equipment (CE), the PW is | From the perspective of a Customer Edge Equipment (CE), the PW is | |||
| characterised as an unshared link or circuit of the chosen service. | characterised as an unshared link or circuit of the chosen service. | |||
| In some cases, there may be deficiencies in the PW emulation that | In some cases, there may be deficiencies in the PW emulation that | |||
| impact the traffic carried over a PW, and hence limit the | impact the traffic carried over a PW, and hence limit the | |||
| applicability of this technology. These limitations must be fully | applicability of this technology. These limitations must be fully | |||
| described in the appropriate service-specific documentation. | described in the appropriate service-specific documentation. | |||
| For each service type, there will be one default mode of operation | For each service type, there will be one default mode of operation | |||
| that all PEs offering that service type MUST support. However, | that all PEs offering that service type must support. However, | |||
| OPTIONAL modes MAY be defined to improve the faithfulness of the | optional modes may be defined to improve the faithfulness of the | |||
| emulated service, if it can be clearly demonstrated that the | emulated service, if it can be clearly demonstrated that the | |||
| additional complexity associated with the OPTIONAL mode is offset by | additional complexity associated with the optional mode is offset by | |||
| the value it offers to PW users. | the value it offers to PW users. | |||
| 1.2 PW Service Functionality | 1.2 PW Service Functionality | |||
| 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 native service. | and characteristics of the native service. | |||
| o Encapsulation of service-specific PDUs or circuit data arriving | o Encapsulation of service-specific PDUs or circuit data arriving | |||
| at the PE-bound port (logical or physical). | at the PE-bound port (logical or physical). | |||
| o Carriage of the encapsulated data across a PSN tunnel. | o Carriage of the encapsulated data across a PSN tunnel. | |||
| o Establishment of the PW including the exchange and/or | o Establishment of the PW including the exchange and/or | |||
| skipping to change at page 7, line 30 ¶ | skipping to change at page 7, line 30 ¶ | |||
| originates and/or terminates. The CE is not | originates and/or terminates. The CE is not | |||
| aware that it is using an emulated service | aware that it is using an emulated service | |||
| rather than a native service. | rather than a native service. | |||
| Forwarder (FWRD) A PE subsystem that selects the PW to use to | Forwarder (FWRD) A PE subsystem that selects the PW to use to | |||
| transmit a payload received on an AC. | transmit a payload received on an AC. | |||
| Fragmentation The action of dividing a single PDU into | Fragmentation The action of dividing a single PDU into | |||
| multiple PDUs before transmission with the | multiple PDUs before transmission with the | |||
| intent of the original PDU being reassembled | intent of the original PDU being reassembled | |||
| elsewhere in the network. Fragmentation MAY be | elsewhere in the network. Fragmentation may be | |||
| performed in order to allow sending of packets | performed in order to allow sending of packets | |||
| of a larger size than the network MTU which | of a larger size than the network MTU which | |||
| they will traverse. | they will traverse. | |||
| Maximum transmission The packet size (excluding data link header) | Maximum transmission The packet size (excluding data link header) | |||
| unit (MTU) that an interface can transmit without | unit (MTU) that an interface can transmit without | |||
| needing to fragment. | needing to fragment. | |||
| Native Service Processing of the data received by the PE | Native Service Processing of the data received by the PE | |||
| Processing (NSP) from the CE before presentation to the PW | Processing (NSP) from the CE before presentation to the PW | |||
| skipping to change at page 10, line 8 ¶ | skipping to change at page 10, line 8 ¶ | |||
| reuse of IETF protocol definitions and their implementations. | reuse of IETF protocol definitions and their implementations. | |||
| 3.1 Protocol Layers | 3.1 Protocol Layers | |||
| The logical protocol-layering model required to support a PW is shown | The logical protocol-layering model required to support a PW is shown | |||
| in Figure 1. | in Figure 1. | |||
| +---------------------------+ | +---------------------------+ | |||
| | Payload | | | Payload | | |||
| +---------------------------+ | +---------------------------+ | |||
| | Encapsulation | <==== MAY be null | | Encapsulation | <==== may be null | |||
| +---------------------------+ | +---------------------------+ | |||
| | PW Demultiplexer | | | PW Demultiplexer | | |||
| +---------------------------+ | +---------------------------+ | |||
| | PSN Convergence | <==== MAY be null | | PSN Convergence | <==== may be null | |||
| +---------------------------+ | +---------------------------+ | |||
| | PSN | | | PSN | | |||
| +---------------------------+ | +---------------------------+ | |||
| | Data-link | | | Data-link | | |||
| +---------------------------+ | +---------------------------+ | |||
| | Physical | | | Physical | | |||
| +---------------------------+ | +---------------------------+ | |||
| Figure 1: Logical Protocol Layering Model | Figure 1: Logical Protocol Layering Model | |||
| skipping to change at page 10, line 36 ¶ | skipping to change at page 10, line 36 ¶ | |||
| interface to send the payload to the CE via the physical interface. | interface to send the payload to the CE via the physical interface. | |||
| If no information is needed beyond that in the payload itself, this | If no information is needed beyond that in the payload itself, this | |||
| layer is empty. | layer is empty. | |||
| This layer also provides support for real-time processing, and | This layer also provides support for real-time processing, and | |||
| sequencing, if needed. | sequencing, if needed. | |||
| The PW Demultiplexer Layer provides the ability to deliver multiple | The PW Demultiplexer Layer provides the ability to deliver multiple | |||
| PWs over a single PSN tunnel. The PW demultiplexer value used to | PWs over a single PSN tunnel. The PW demultiplexer value used to | |||
| identify the PW in the data-plane may be unique per PE, but this is | identify the PW in the data-plane may be unique per PE, but this is | |||
| not a PWE3 requirement. It MUST, however, be unique per tunnel | not a PWE3 requirement. It must, however, be unique per tunnel | |||
| endpoint. If it is necessary to identify a particular tunnel, then | endpoint. If it is necessary to identify a particular tunnel, then | |||
| that is the responsibility of the PSN layer. | that is the responsibility of the PSN layer. | |||
| The PSN Convergence Layer provides the enhancements needed to make | The PSN Convergence Layer provides the enhancements needed to make | |||
| the PSN conform to the assumed PSN service requirement. This layer | the PSN conform to the assumed PSN service requirement. This layer | |||
| therefore provides a consistent interface to the PW, making the PW | therefore provides a consistent interface to the PW, making the PW | |||
| independent of the PSN type. If the PSN already meets the service | independent of the PSN type. If the PSN already meets the service | |||
| requirements, this layer is empty. | requirements, this layer is empty. | |||
| The PSN header, MAC/Data-link and Physical Layer definitions are | The PSN header, MAC/Data-link and Physical Layer definitions are | |||
| skipping to change at page 12, line 8 ¶ | skipping to change at page 12, line 8 ¶ | |||
| unit. However, there will be cases where the combined size of the | unit. However, there will be cases where the combined size of the | |||
| packet payload and its associated PWE3 and PSN headers exceeds the | packet payload and its associated PWE3 and PSN headers exceeds the | |||
| PSN path MTU. In these cases, some fragmentation methodology needs | PSN path MTU. In these cases, some fragmentation methodology needs | |||
| to be applied. This may, for example, be the case when a user is | to be applied. This may, for example, be the case when a user is | |||
| providing the service and attaching to the service provider via | providing the service and attaching to the service provider via | |||
| Ethernet, or where nested pseudo-wires are involved. Fragmentation is | Ethernet, or where nested pseudo-wires are involved. Fragmentation is | |||
| discussed in more detail in Section 5.3 | discussed in more detail in Section 5.3 | |||
| A packet payload may need sequencing and real-time support. | A packet payload may need sequencing and real-time support. | |||
| In some situations, the packet payload MAY be selected from the | In some situations, the packet payload may be selected from the | |||
| packets presented on the emulated wire on the basis of some sub- | packets presented on the emulated wire on the basis of some sub- | |||
| multiplexing technique. For example, one or more frame-relay PDUs | multiplexing technique. For example, one or more frame-relay PDUs | |||
| may be selected for transport over a particular pseudo-wire based on | may be selected for transport over a particular pseudo-wire based on | |||
| the frame-relay Data-Link Connection Identifier (DLCI), or, in the | the frame-relay Data-Link Connection Identifier (DLCI), or, in the | |||
| case of Ethernet payloads, using a suitable MAC bridge filter. This | case of Ethernet payloads, using a suitable MAC bridge filter. This | |||
| is a forwarder function, and this selection would therefore be made | is a forwarder function, and this selection would therefore be made | |||
| before the packet was presented to the PW Encapsulation Layer. | before the packet was presented to the PW Encapsulation Layer. | |||
| 3.3.2. Cell Payload | 3.3.2. Cell Payload | |||
| A cell payload is created by capturing, transporting and replaying | A cell payload is created by capturing, transporting and replaying | |||
| groups of octets presented on the wire in a fixed-size format. The | groups of octets presented on the wire in a fixed-size format. The | |||
| delineation of the group of bits that comprise the cell is specific | delineation of the group of bits that comprise the cell is specific | |||
| to the encapsulation type. Two common examples of cell payloads are | to the encapsulation type. Two common examples of cell payloads are | |||
| ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream | ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream | |||
| packets [DVB]. | packets [DVB]. | |||
| To reduce per-PSN packet overhead, multiple cells MAY be concatenated | To reduce per-PSN packet overhead, multiple cells may be concatenated | |||
| into a single payload. The Encapsulation Layer MAY consider the | into a single payload. The Encapsulation Layer may consider the | |||
| payload complete on the expiry of a timer, after a fixed number of | payload complete on the expiry of a timer, after a fixed number of | |||
| cells have been received or when a significant cell (e.g. an ATM OAM | cells have been received or when a significant cell (e.g. an ATM OAM | |||
| cell) has been received. The benefit of concatenating multiple PDUs | cell) has been received. The benefit of concatenating multiple PDUs | |||
| should be weighed against a possible increase in packet delay | should be weighed against a possible increase in packet delay | |||
| variation and the larger penalty incurred by packet loss. In some | variation and the larger penalty incurred by packet loss. In some | |||
| cases, it may be appropriate for the Encapsulation Layer to perform | cases, it may be appropriate for the Encapsulation Layer to perform | |||
| some type of compression, such as silence suppression or voice | some type of compression, such as silence suppression or voice | |||
| compression. | compression. | |||
| The generic cell payload service will normally need sequence number | The generic cell payload service will normally need sequence number | |||
| support, and may also need real-time support. The generic cell | support, and may also need real-time support. The generic cell | |||
| payload service would not normally require fragmentation. | payload service would not normally require fragmentation. | |||
| The Encapsulation Layer MAY apply some form of compression to some of | The Encapsulation Layer may apply some form of compression to some of | |||
| these sub-types (e.g. idle cells MAY be suppressed). | these sub-types (e.g. idle cells may be suppressed). | |||
| In some instances, the cells to be incorporated in the payload MAY be | In some instances, the cells to be incorporated in the payload may be | |||
| selected by filtering them from the stream of cells presented on the | selected by filtering them from the stream of cells presented on the | |||
| wire. For example, an ATM PWE3 service may select cells based on | wire. For example, an ATM PWE3 service may select cells based on | |||
| their VCI or VPI fields. This is a forwader function, and the | their VCI or VPI fields. This is a forwader function, and the | |||
| selection would therefore be made before the packet was presented to | selection would therefore be made before the packet was presented to | |||
| the PW Encapsulation Layer. | the PW Encapsulation Layer. | |||
| 3.3.3. Bit-stream | 3.3.3. Bit-stream | |||
| A bit-stream payload is created by capturing, transporting and | A bit-stream payload is created by capturing, transporting and | |||
| replaying the bit pattern on the emulated wire, without taking | replaying the bit pattern on the emulated wire, without taking | |||
| skipping to change at page 13, line 29 ¶ | skipping to change at page 13, line 29 ¶ | |||
| 3.3.4. Structured bit-stream | 3.3.4. Structured bit-stream | |||
| A structured bit-stream payload is created by using some knowledge of | A structured bit-stream payload is created by using some knowledge of | |||
| the underlying structure of the bit-stream to capture, transport and | the underlying structure of the bit-stream to capture, transport and | |||
| replay the bit pattern on the emulated wire. | replay the bit pattern on the emulated wire. | |||
| Two important points distinguish structured and unstructured bit- | Two important points distinguish structured and unstructured bit- | |||
| streams: | streams: | |||
| o Some parts of the original bit-stream MAY be stripped in the | o Some parts of the original bit-stream may be stripped in the | |||
| PSN-bound direction by NSP block. For example, in Structured | PSN-bound direction by NSP block. For example, in Structured | |||
| SONET the section and line overhead (and, possibly more) may | SONET the section and line overhead (and, possibly more) may | |||
| be stripped. A framer is required to enable such stripping. | be stripped. A framer is required to enable such stripping. | |||
| It is also required for frame/payload alignment for | It is also required for frame/payload alignment for | |||
| fractional T1/E1 applications. | fractional T1/E1 applications. | |||
| o The PW MUST preserve the structure across the PSN so that | o The PW must preserve the structure across the PSN so that | |||
| the CE-bound NSP block can insert it correctly into the | the CE-bound NSP block can insert it correctly into the | |||
| reconstructed unstructured bit-stream. The stripped | reconstructed unstructured bit-stream. The stripped | |||
| information (such as SONET pointer justifications) may | information (such as SONET pointer justifications) may | |||
| appear in the encapsulation layer to facilitate this | appear in the encapsulation layer to facilitate this | |||
| reconstitution. | reconstitution. | |||
| As an option, the Encapsulation Layer MAY also perform silence/idle | As an option, the Encapsulation Layer may also perform silence/idle | |||
| suppression or similar compression on a structured bit-stream. | suppression or similar compression on a structured bit-stream. | |||
| Structured bit-streams are distinguished from cells in that the | Structured bit-streams are distinguished from cells in that the | |||
| structures may be too long to be carried in a single packet. Note | structures may be too long to be carried in a single packet. Note | |||
| that "short" structures are indistinguishable from cells and may | that "short" structures are indistinguishable from cells and may | |||
| benefit from the use of methods described in section 3.3.2. | benefit from the use of methods described in section 3.3.2. | |||
| This service REQUIRES sequencing and real-time support. | This service requires sequencing and real-time support. | |||
| 3.3.5. Principle of Minimum Intervention | 3.3.5. Principle of Minimum Intervention | |||
| To minimise the scope of information, and to improve the efficiency | To minimise the scope of information, and to improve the efficiency | |||
| of data flow through the Encapsulation Layer, the payload SHOULD be | of data flow through the Encapsulation Layer, the payload should be | |||
| transported as received with as few modifications as possible | transported as received with as few modifications as possible | |||
| [RFC1958]. | [RFC1958]. | |||
| This minimum intervention approach decouples payload development from | This minimum intervention approach decouples payload development from | |||
| PW development and requires fewer translations at the NSP in a system | PW development and requires fewer translations at the NSP in a system | |||
| with similar CE interfaces at each end. It also prevents unwanted | with similar CE interfaces at each end. It also prevents unwanted | |||
| side-effects due to subtle misrepresentation of the payload in the | side-effects due to subtle misrepresentation of the payload in the | |||
| intermediate format. | intermediate format. | |||
| An approach which does intervene can be more wire-efficient in some | An approach which does intervene can be more wire-efficient in some | |||
| skipping to change at page 15, line 10 ¶ | skipping to change at page 15, line 10 ¶ | |||
| 4.1 Network Reference Model | 4.1 Network Reference Model | |||
| Figure 2 illustrates the network reference model for point-to-point | Figure 2 illustrates the network reference model for point-to-point | |||
| PWs. | PWs. | |||
| |<-------------- Emulated Service ---------------->| | |<-------------- Emulated Service ---------------->| | |||
| | | | | | | |||
| | |<------- Pseudo Wire ------>| | | | |<------- Pseudo Wire ------>| | | |||
| | | | | | | | | | | |||
| | | |<-- PSN Tunnel -->| | | | | | |<-- PSN Tunnel -->| | | | |||
| | PW End V V V V PW End | | | V V V V | | |||
| V Service +----+ +----+ Service V | V AC +----+ +----+ AC V | |||
| +-----+ | | PE1|==================| PE2| | +-----+ | +-----+ | | PE1|==================| PE2| | +-----+ | |||
| | |----------|............PW1.............|----------| | | | |----------|............PW1.............|----------| | | |||
| | CE1 | | | | | | | | CE2 | | | CE1 | | | | | | | | CE2 | | |||
| | |----------|............PW2.............|----------| | | | |----------|............PW2.............|----------| | | |||
| +-----+ ^ | | |==================| | | ^ +-----+ | +-----+ ^ | | |==================| | | ^ +-----+ | |||
| ^ | +----+ +----+ | | ^ | ^ | +----+ +----+ | | ^ | |||
| | | Provider Edge 1 Provider Edge 2 | | | | | Provider Edge 1 Provider Edge 2 | | | |||
| | | | | | | | | | | |||
| Customer | | Customer | Customer | | Customer | |||
| Edge 1 | | Edge 2 | Edge 1 | | Edge 2 | |||
| skipping to change at page 18, line 4 ¶ | skipping to change at page 18, line 4 ¶ | |||
| +----------------------------------------+ | +----------------------------------------+ | |||
| Figure 4b: Multiple AC to Multiple PW Forwarding | Figure 4b: Multiple AC to Multiple PW Forwarding | |||
| Figure 4a shows a simple forwarder that performs some type of | Figure 4a shows a simple forwarder that performs some type of | |||
| filtering operation. Because the forwarder has a single input and a | filtering operation. Because the forwarder has a single input and a | |||
| single output interface, filtering is the only type of forwarding | single output interface, filtering is the only type of forwarding | |||
| operation that applies. Figure 4b shows a more general forwarding | operation that applies. Figure 4b shows a more general forwarding | |||
| situation where payloads are extracted from one or more ACs and | situation where payloads are extracted from one or more ACs and | |||
| directed to one or more PWs. In this case filtering, direction and | directed to one or more PWs. In this case filtering, direction and | |||
| combination operations MAY be performed on the payloads. For | combination operations may be performed on the payloads. For | |||
| example, if the AC were frame relay, the forwarder might perform | example, if the AC were frame relay, the forwarder might perform | |||
| frame relay switching and the PW instances might be the inter-switch | frame relay switching and the PW instances might be the inter-switch | |||
| links. | links. | |||
| 4.2.2. Native Service Processing | 4.2.2. Native Service Processing | |||
| In some applications some form of data or address translation, or | In some applications some form of data or address translation, or | |||
| other operation requiring knowledge of the semantics of the payload, | other operation requiring knowledge of the semantics of the payload, | |||
| will be required. This is the function of the Native Service | will be required. This is the function of the Native Service | |||
| Processor (NSP). | Processor (NSP). | |||
| skipping to change at page 18, line 42 ¶ | skipping to change at page 18, line 42 ¶ | |||
| |------| |----------------------| | |------| |----------------------| | |||
| | | | Single | PW Instance | | | | Single | PW Instance | |||
| <------>o NSP # + PW Instance X<===========> | <------>o NSP # + PW Instance X<===========> | |||
| | | | | | | | | | | |||
| +----------------------------------------+ | +----------------------------------------+ | |||
| Figure 5: NSP in a Multiple AC to Multiple | Figure 5: NSP in a Multiple AC to Multiple | |||
| PW Forwarding PE | PW Forwarding PE | |||
| Figure 5 illustrates the relationship between NSP, forwarder and PWs | Figure 5 illustrates the relationship between NSP, forwarder and PWs | |||
| in a PE. The NSP function MAY apply any transformation operation | in a PE. The NSP function may apply any transformation operation | |||
| (modification, injection, etc.) on the payloads as they pass between | (modification, injection, etc.) on the payloads as they pass between | |||
| the physical interface to the CE and the virtual interface to the | the physical interface to the CE and the virtual interface to the | |||
| forwarder. These transformation operations will of course be limited | forwarder. These transformation operations will of course be limited | |||
| to those that have been implemented in the data path, and which are | to those that have been implemented in the data path, and which are | |||
| enabled by the PE configuration. A PE device MAY contain more than | enabled by the PE configuration. A PE device may contain more than | |||
| one forwarder. | one forwarder. | |||
| This model also supports the operation of a system in which the NSP | This model also supports the operation of a system in which the NSP | |||
| functionality includes terminating the data-link, and applying | functionality includes terminating the data-link, and applying | |||
| Network Layer processing to the payload is also supported. | Network Layer processing to the payload is also supported. | |||
| 4.3 Maintenance Reference Model | 4.3 Maintenance Reference Model | |||
| Figure 6 illustrates the maintenance reference model for PWs. | Figure 6 illustrates the maintenance reference model for PWs. | |||
| skipping to change at page 19, line 30 ¶ | skipping to change at page 19, line 30 ¶ | |||
| | |-----|.............PW1..............|-----| | | | |-----|.............PW1..............|-----| | | |||
| | CE1 | | | | | | CE2 | | | CE1 | | | | | | CE2 | | |||
| | |-----|.............PW2..............|-----| | | | |-----|.............PW2..............|-----| | | |||
| +-----+ | |==================| | +-----+ | +-----+ | |==================| | +-----+ | |||
| +-----+ +-----+ | +-----+ +-----+ | |||
| Customer Provider Provider Customer | Customer Provider Provider Customer | |||
| Edge 1 Edge 1 Edge 2 Edge 2 | Edge 1 Edge 1 Edge 2 Edge 2 | |||
| Figure 6: PWE3 Maintenance Reference Model | Figure 6: PWE3 Maintenance Reference Model | |||
| The following signaling mechanisms are REQUIRED: | The following signaling mechanisms are required: | |||
| o The CE (end-to-end) signaling is between the CEs. This | o The CE (end-to-end) signaling is between the CEs. This | |||
| signaling could be frame relay PVC status signaling, ATM SVC | signaling could be frame relay PVC status signaling, ATM SVC | |||
| signaling, TDM CAS signaling, etc. | signaling, TDM CAS signaling, etc. | |||
| o The PW/PE Maintenance is used between the PEs (or NSPs) to set | o The PW/PE Maintenance is used between the PEs (or NSPs) to set | |||
| up, maintain and tear down PWs, including any required | up, maintain and tear down PWs, including any required | |||
| coordination of parameters. | coordination of parameters. | |||
| o The PSN Tunnel signaling controls the PW multiplexing and some | o The PSN Tunnel signaling controls the PW multiplexing and some | |||
| skipping to change at page 22, line 49 ¶ | skipping to change at page 22, line 49 ¶ | |||
| The Timing Layer and the Sequencing Layer provide generic services to | The Timing Layer and the Sequencing Layer provide generic services to | |||
| the Payload Convergence Layer for all payload types that require | the Payload Convergence Layer for all payload types that require | |||
| them. | them. | |||
| 5.1 Payload Convergence Layer | 5.1 Payload Convergence Layer | |||
| 5.1.1. Encapsulation | 5.1.1. Encapsulation | |||
| The primary task of the Payload Convergence Layer is the | The primary task of the Payload Convergence Layer is the | |||
| encapsulation of the payload in PW-PDUs. The native data units to be | encapsulation of the payload in PW-PDUs. The native data units to be | |||
| encapsulated MAY contain a L2 header or L1 overhead. This is service | encapsulated may contain a L2 header or L1 overhead. This is service | |||
| specific. The Payload Convergence header carries the additional | specific. The Payload Convergence header carries the additional | |||
| information needed to replay the native data units at the CE-bound | information needed to replay the native data units at the CE-bound | |||
| physical interface. The PW Demultiplexer header is not considered as | physical interface. The PW Demultiplexer header is not considered as | |||
| part of the PW header. | part of the PW header. | |||
| Not all the additional information needed to replay the native data | Not all the additional information needed to replay the native data | |||
| units need to be carried in the PW header of the PW PDUs. Some | units need to be carried in the PW header of the PW PDUs. Some | |||
| information (e.g. service type of a PW) MAY be stored as state | information (e.g. service type of a PW) may be stored as state | |||
| information at the destination PE during PW set-up. | information at the destination PE during PW set-up. | |||
| 5.1.2. PWE3 Channel Types | 5.1.2. PWE3 Channel Types | |||
| The PW Encapsulation Layer and its associated signaling require one | The PW Encapsulation Layer and its associated signaling require one | |||
| or more of the following types of channels from its underlying PW | or more of the following types of channels from its underlying PW | |||
| Demultiplexer and PSN Layers: | Demultiplexer and PSN Layers: | |||
| 1. A reliable control channel for signaling line events, status | 1. A reliable control channel for signaling line events, status | |||
| indications, and, in some exceptional cases, CE-CE events | indications, and, in some exceptional cases, CE-CE events | |||
| that must be translated and sent reliably between PEs. | that must be translated and sent reliably between PEs. | |||
| PWE3 may need this type of control channel to provide | ||||
| For example, this capability is needed in [PPPoL2TP] | faithful emulation of complex data-link protocols. | |||
| (PPP negotiation has to be split between the two ends of the | ||||
| tunnel). PWE3 may also need this type of control channel to | ||||
| provide faithful emulation of complex data-link protocols. | ||||
| plus one or more data channels with the following characteristics: | plus one or more data channels with the following characteristics: | |||
| 2. A high-priority, unreliable, sequenced channel. A typical use | 2. A high-priority, unreliable, sequenced channel. A typical use | |||
| is for CE-to-CE signaling. "High priority" may simply be | is for CE-to-CE signaling. "High priority" may simply be | |||
| indicated via the DSCP bits for IP or the EXP bits for MPLS, | indicated via the DSCP bits for IP or the EXP bits for MPLS, | |||
| giving the packet priority during transit. This channel type | giving the packet priority during transit. This channel type | |||
| could also use a bit in the tunnel header itself to indicate | could also use a bit in the tunnel header itself to indicate | |||
| that packets received at the PE SHOULD be processed with higher | that packets received at the PE should be processed with higher | |||
| priority [RFC2474]. | priority [RFC2474]. | |||
| 3. A sequenced channel for data traffic that is sensitive to | 3. A sequenced channel for data traffic that is sensitive to | |||
| packet reordering (one classification for use could be for | packet reordering (one classification for use could be for | |||
| any non-IP traffic). | any non-IP traffic). | |||
| 4. An un-sequenced channel for data traffic insensitive to packet | 4. An un-sequenced channel for data traffic insensitive to packet | |||
| order. | order. | |||
| The data channels (2, 3 and 4 above) SHOULD be carried "in band" with | The data channels (2, 3 and 4 above) should be carried "in band" with | |||
| one another to as much of a degree as is reasonably possible on a | one another to as much of a degree as is reasonably possible on a | |||
| PSN. | PSN. | |||
| Where end-to-end connectivity may be disrupted by address translation | Where end-to-end connectivity may be disrupted by address translation | |||
| [RFC3022], access-control lists, firewalls etc., there exists the | [RFC3022], access-control lists, firewalls etc., there exists the | |||
| possibility that the control channel may be able to pass traffic and | possibility that the control channel may be able to pass traffic and | |||
| set-up the PW, but the PW data traffic is blocked by one or more of | set-up the PW, but the PW data traffic is blocked by one or more of | |||
| these mechanisms. In these cases unless the control channel is also | these mechanisms. In these cases unless the control channel is also | |||
| carried "in band" the signaling to set-up the PW will not confirm the | carried "in band" the signaling to set-up the PW will not confirm the | |||
| existence of an end-to-end data path. | existence of an end-to-end data path. | |||
| skipping to change at page 24, line 26 ¶ | skipping to change at page 24, line 24 ¶ | |||
| 5.1.3. Quality of Service Considerations | 5.1.3. Quality of Service Considerations | |||
| Where possible, it is desirable to employ mechanisms to provide PW | Where possible, it is desirable to employ mechanisms to provide PW | |||
| Quality of Service (QoS) support over PSNs. | Quality of Service (QoS) support over PSNs. | |||
| 5.2 Payload-independent PW Encapsulation Layers | 5.2 Payload-independent PW Encapsulation Layers | |||
| Two PWE3 Encapsulation Sub-layers provide common services to all | Two PWE3 Encapsulation Sub-layers provide common services to all | |||
| payload types: Sequencing and Timing. These services are optional | payload types: Sequencing and Timing. These services are optional | |||
| and are only used if needed by a particular PW instance. If the | and are only used if needed by a particular PW instance. If the | |||
| service is not needed, the associated header MAY be omitted in order | service is not needed, the associated header may be omitted in order | |||
| to conserve processing and network resources. | to conserve processing and network resources. | |||
| There will be instances where a specific payload type will be | There will be instances where a specific payload type will be | |||
| required to be transported with or without sequence and/or real-time | required to be transported with or without sequence and/or real-time | |||
| support. For example, an invariant of frame relay transport is the | support. For example, an invariant of frame relay transport is the | |||
| preservation of packet order. Some frame-relay applications expect | preservation of packet order. Some frame-relay applications expect | |||
| in-order delivery, and may not cope with reordering of the frames. | in-order delivery, and may not cope with reordering of the frames. | |||
| However, where the frame relay service is itself only being used to | However, where the frame relay service is itself only being used to | |||
| carry IP, it may be desirable to relax that constraint in return for | carry IP, it may be desirable to relax that constraint in return for | |||
| reduced per-packet processing cost. | reduced per-packet processing cost. | |||
| The guiding principle is that, where possible, an existing IETF | The guiding principle is that, where possible, an existing IETF | |||
| protocol SHOULD be used to provide these services. Where a suitable | protocol should be used to provide these services. Where a suitable | |||
| protocol is not available, the existing protocol should be extended | protocol is not available, the existing protocol should be extended | |||
| or modified to meet the PWE3 requirements, thereby making that | or modified to meet the PWE3 requirements, thereby making that | |||
| protocol available for other IETF uses. In the particular case of | protocol available for other IETF uses. In the particular case of | |||
| timing, more than one general method may be necessary to provide for | timing, more than one general method may be necessary to provide for | |||
| the full scope of payload timing requirements. | the full scope of payload timing requirements. | |||
| 5.2.1. Sequencing | 5.2.1. Sequencing | |||
| The sequencing function provides three services: frame ordering, | The sequencing function provides three services: frame ordering, | |||
| frame duplication detection and frame loss detection. These services | frame duplication detection and frame loss detection. These services | |||
| allow the emulation of the invariant properties of a physical wire. | allow the emulation of the invariant properties of a physical wire. | |||
| Support for sequencing depends on the payload type, and MAY be | Support for sequencing depends on the payload type, and may be | |||
| omitted if not needed. | omitted if not needed. | |||
| The size of the sequence-number space depends on the speed of the | The size of the sequence-number space depends on the speed of the | |||
| emulated service, and the maximum time of the transient conditions in | emulated service, and the maximum time of the transient conditions in | |||
| the PSN. A sequence number space greater than 2^16 may therefore be | the PSN. A sequence number space greater than 2^16 may therefore be | |||
| needed to prevent the sequence number space wrapping during the | needed to prevent the sequence number space wrapping during the | |||
| transient. | transient. | |||
| 5.2.1.1 Frame Ordering | 5.2.1.1 Frame Ordering | |||
| When packets carrying the PW-PDUs traverse a PSN, they may arrive out | When packets carrying the PW-PDUs traverse a PSN, they may arrive out | |||
| of order at the destination PE. For some services, the frames | of order at the destination PE. For some services, the frames | |||
| (control frames, data frames, or both control and data frames) MUST | (control frames, data frames, or both control and data frames) must | |||
| be delivered in order. For such services, some mechanism MUST be | be delivered in order. For such services, some mechanism must be | |||
| provided for ensuring in-order delivery. Providing a sequence number | provided for ensuring in-order delivery. Providing a sequence number | |||
| in the sequence sub-layer header for each packet is one possible | in the sequence sub-layer header for each packet is one possible | |||
| approach to out-of-sequence detection. Alternatively it can be noted | approach to out-of-sequence detection. Alternatively it can be noted | |||
| that sequencing is a subset of the problem of delivering timed | that sequencing is a subset of the problem of delivering timed | |||
| packets, and that a single combined mechanism such as [RFC3550] MAY | packets, and that a single combined mechanism such as [RFC3550] may | |||
| be employed. | be employed. | |||
| There are two possible misordering strategies: | There are two possible misordering strategies: | |||
| o Drop misordered PW PDUs. | o Drop misordered PW PDUs. | |||
| o Try to sort PW PDUs into the correct order. | o Try to sort PW PDUs into the correct order. | |||
| The choice of strategy will depend on: | The choice of strategy will depend on: | |||
| skipping to change at page 25, line 47 ¶ | skipping to change at page 25, line 44 ¶ | |||
| o The acceptable delay (since delay must be introduced to | o The acceptable delay (since delay must be introduced to | |||
| reorder) | reorder) | |||
| o The incidence of expected misordering. | o The incidence of expected misordering. | |||
| 5.2.1.2 Frame Duplication Detection | 5.2.1.2 Frame Duplication Detection | |||
| In rare cases, packets traversing a PW may be duplicated by the | In rare cases, packets traversing a PW may be duplicated by the | |||
| underlying PSN. For some services frame duplication is not | underlying PSN. For some services frame duplication is not | |||
| acceptable. For such services, some mechanism MUST be provided to | acceptable. For such services, some mechanism must be provided to | |||
| ensure that duplicated frames will not be delivered to the | ensure that duplicated frames will not be delivered to the | |||
| destination CE. The mechanism MAY be the same as the mechanism used | destination CE. The mechanism may be the same as the mechanism used | |||
| to ensure in-order frame delivery. | to ensure in-order frame delivery. | |||
| 5.2.1.3 Frame Loss Detection | 5.2.1.3 Frame Loss Detection | |||
| A destination PE can determine whether a frame has been lost by | A destination PE can determine whether a frame has been lost by | |||
| tracking the sequence numbers of the received PW PDUs. | tracking the sequence numbers of the received PW PDUs. | |||
| In some instances, a destination PE will have to presume that a PW | In some instances, a destination PE will have to presume that a PW | |||
| PDU is lost if it fails to arrive within a certain time. If a PW-PDU | PDU is lost if it fails to arrive within a certain time. If a PW-PDU | |||
| that has been processed as lost subsequently arrives, the destination | that has been processed as lost subsequently arrives, the destination | |||
| PE MUST discard it. | PE must discard it. | |||
| 5.2.2. Timing | 5.2.2. Timing | |||
| A number of native services have timing expectations based on the | A number of native services have timing expectations based on the | |||
| characteristics of the networks that they were designed to travel | characteristics of the networks that they were designed to travel | |||
| over, and it can be necessary for the emulated service to duplicate | over, and it can be necessary for the emulated service to duplicate | |||
| these network characteristics as closely as possible, e.g. in | these network characteristics as closely as possible, e.g. in | |||
| delivering native traffic with bit-rate, jitter, wander and delay | delivering native traffic with bit-rate, jitter, wander and delay | |||
| characteristics similar to those received at the sending PE. | characteristics similar to those received at the sending PE. | |||
| skipping to change at page 27, line 14 ¶ | skipping to change at page 27, line 14 ¶ | |||
| 5.3 Fragmentation | 5.3 Fragmentation | |||
| A payload would ideally be relayed across the PW as a single unit. | A payload would ideally be relayed across the PW as a single unit. | |||
| However, there will be cases where the combined size of the payload | However, there will be cases where the combined size of the payload | |||
| and its associated PWE3 and PSN headers exceeds the PSN path MTU. | and its associated PWE3 and PSN headers exceeds the PSN path MTU. | |||
| When a packet size exceeds the MTU of a given network, fragmentation | When a packet size exceeds the MTU of a given network, fragmentation | |||
| and reassembly have to be performed in order for the packet to be | and reassembly have to be performed in order for the packet to be | |||
| delivered. Since fragmentation and reassembly generally consume a | delivered. Since fragmentation and reassembly generally consume a | |||
| considerable network resources as compared to simply switching a | considerable network resources as compared to simply switching a | |||
| packet in its entirety, efforts SHOULD be made to reduce or eliminate | packet in its entirety, efforts should be made to reduce or eliminate | |||
| the need for fragmentation and reassembly throughout a network to the | the need for fragmentation and reassembly throughout a network to the | |||
| extent possible. Of particular concern for fragmentation and | extent possible. Of particular concern for fragmentation and | |||
| reassembly are aggregation points where large numbers of PWs are | reassembly are aggregation points where large numbers of PWs are | |||
| processed (e.g. at the PE). | processed (e.g. at the PE). | |||
| Ideally, the equipment originating the traffic being sent over the PW | Ideally, the equipment originating the traffic being sent over the PW | |||
| will be configured to have adaptive measures (e.g. [RFC1191], | will be configured to have adaptive measures (e.g. [RFC1191], | |||
| [RFC1981]) in place that ensure that packets that need to be | [RFC1981]) in place that ensure that packets that need to be | |||
| fragmented are not sent. When this fails, the point closest to the | fragmented are not sent. When this fails, the point closest to the | |||
| sending host with fragmentation and reassembly capabilities SHOULD | sending host with fragmentation and reassembly capabilities should | |||
| attempt to reduce the size of packets to satisfy the PSN MTU. Thus, | attempt to reduce the size of packets to satisfy the PSN MTU. Thus, | |||
| in the reference model for PWE3 [Figure 3] fragmentation SHOULD first | in the reference model for PWE3 [Figure 3] fragmentation should first | |||
| be performed at the CE if at all possible. If and only if the CE | be performed at the CE if at all possible. If and only if the CE | |||
| cannot adhere to an acceptable MTU size for the PW should the PE | cannot adhere to an acceptable MTU size for the PW should the PE | |||
| attempt its own fragmentation method. | attempt its own fragmentation method. | |||
| In cases where MTU management fails to limit the payload to a size | In cases where MTU management fails to limit the payload to a size | |||
| suitable for transmission of the PW, the PE MAY fall back to either a | suitable for transmission of the PW, the PE may fall back to either a | |||
| generic PW fragmentation method, or, if available the fragmentation | generic PW fragmentation method, or, if available the fragmentation | |||
| service of the underlying PSN. | service of the underlying PSN. | |||
| It is acceptable for a PE implementation not to support | It is acceptable for a PE implementation not to support | |||
| fragmentation. A PE that does not support fragmentation will drop | fragmentation. A PE that does not support fragmentation will drop | |||
| packets that exceed the PSN MTU, and the management plane of the | packets that exceed the PSN MTU, and the management plane of the | |||
| encapsulating PE MAY be notified. | encapsulating PE may be notified. | |||
| If the length of a L2/L1 frame, restored from a PW PDU, exceeds the | If the length of a L2/L1 frame, restored from a PW PDU, exceeds the | |||
| MTU of the destination AC, it MUST be dropped. In this case, the | MTU of the destination AC, it must be dropped. In this case, the | |||
| management plane of the destination PE MAY be notified. | management plane of the destination PE may be notified. | |||
| 5.4 Instantiation of the Protocol Layers | 5.4 Instantiation of the Protocol Layers | |||
| This document does not address the detailed mapping of the Protocol | This document does not address the detailed mapping of the Protocol | |||
| Layering model to existing or future IETF standards. The | Layering model to existing or future IETF standards. The | |||
| instantiation of the logical Protocol Layering model is shown in | instantiation of the logical Protocol Layering model is shown in | |||
| Figure 9. | Figure 9. | |||
| 5.4.1. PWE3 over an IP PSN | 5.4.1. PWE3 over an IP PSN | |||
| The protocol definition of PWE3 over an IP PSN SHOULD employ existing | The protocol definition of PWE3 over an IP PSN should employ existing | |||
| IETF protocols where possible. | IETF protocols where possible. | |||
| +---------------------+ +-------------------------+ | +---------------------+ +-------------------------+ | |||
| | Payload |------------->| Raw payload if possible | | | Payload |------------->| Raw payload if possible | | |||
| /=====================\ +-------------------------+ | /=====================\ +-------------------------+ | |||
| H Payload Convergence H-----------+->| As Needed | | H Payload Convergence H-----------+->| Flags, seq # etc. | | |||
| H---------------------H / +-------------------------+ | H---------------------H / +-------------------------+ | |||
| H Timing H---------/--->| RTP | | H Timing H---------/--->| RTP | | |||
| H---------------------H / +-------------+ | | H---------------------H / +-------------+ | | |||
| H Sequencing H----one of | | | H Sequencing H----one of | | | |||
| \=====================/ \ | +-----------+ | \=====================/ \ | +-----------+ | |||
| | PW Demultiplexer |---------+--->| L2TP, MPLS etc. | | | PW Demultiplexer |---------+--->| L2TP, MPLS etc. | | |||
| +---------------------+ +-------------------------+ | +---------------------+ +-------------------------+ | |||
| | PSN Convergence |------------->| Not needed | | | PSN Convergence |------------->| Not needed | | |||
| +---------------------+ +-------------------------+ | +---------------------+ +-------------------------+ | |||
| | PSN |------------->| IP | | | PSN |------------->| IP | | |||
| +---------------------+ +-------------------------+ | +---------------------+ +-------------------------+ | |||
| | Data-link |------------->| Data-link | | | Data-link |------------->| Data-link | | |||
| +---------------------+ +-------------------------+ | +---------------------+ +-------------------------+ | |||
| | Physical |------------->| Physical | | | Physical |------------->| Physical | | |||
| +---------------------+ +-------------------------+ | +---------------------+ +-------------------------+ | |||
| Figure 10: PWE3 over an IP PSN | Figure 10: PWE3 over an IP PSN | |||
| Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a | Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a | |||
| rule, the payload SHOULD be carried as received from the NSP, with | rule, the payload should be carried as received from the NSP, with | |||
| the Payload Convergence Layer provided when needed. (It is accepted | the Payload Convergence Layer provided when needed. However in | |||
| that there MAY sometimes be good reason not to follow this rule, but | certain circumstances it may be justifiable to transmit the payload | |||
| the exceptional circumstances need to be documented in the | in some processed form. The reasons for this must be documented in | |||
| Encapsulation Layer definition for that payload type). | the Encapsulation Layer definition for that payload type. | |||
| Where appropriate, timing is provided by RTP [RFC3550], which when | Where appropriate, explicit timing is provided by RTP [RFC3550], | |||
| used also provides a sequencing service. PW Demultiplexing may be | which when used also provides a sequencing service. When the PSN is | |||
| provided by a number of existing IETF tunnel protocols. Some of | UDP/IP, the RTP header follows the UDP header and precedes the PW | |||
| these tunnel protocols provide an optional sequencing service. | control field, while for all other cases the RTP header follows the | |||
| (Sequencing is provided either by RTP, or by the PW Demultiplexer | PW control header. | |||
| Layer, but not both). | ||||
| RTP is normally carried over UDP, however the tunnel protcols that | The encapsulation layer may additionally carry a sequence number; | |||
| are capable of carrying a PW, provide sufficient functionality to | sequencing is to be provided either by RTP, or by the PW | |||
| carry RTP without an intervening transport layer. UDP MAY therefore | encapsulation layer but not both. | |||
| be omitted from the protocol stack. | ||||
| A PSN Convergence Layer is not needed, because all the tunnel | PW Demultiplexing is provided by the PW label, which may take the | |||
| protocols shown above are designed to operate directly over an IP | form specified in a number of IETF protocols, e.g. an MPLS label | |||
| PSN. | [MPLSIP], an L2TP session ID [L2TPv3], or a UDP port number [RFC768]. | |||
| When PWs are carried over IP the PSN Convergence Layer will not be | ||||
| needed. | ||||
| As a special case, if the PW Demultiplexer is an MPLS label, the | As a special case, if the PW Demultiplexer is an MPLS label, the | |||
| protocol architecture of section 5.4.2 can be used instead of the | protocol architecture of section 5.4.2 can be used instead of the | |||
| protocol architecture of this section. | protocol architecture of this section. | |||
| 5.4.2. PWE3 over an MPLS PSN | 5.4.2. PWE3 over an MPLS PSN | |||
| The MPLS ethos places importance on wire efficiency. By using a | The MPLS ethos places importance on wire efficiency. By using a | |||
| control word, some components of the PWE3 protocol layers can be | control word, some components of the PWE3 protocol layers can be | |||
| compressed to increase this efficiency. | compressed to increase this efficiency. | |||
| +---------------------+ | +---------------------+ | |||
| | Payload | | | Payload | | |||
| /=====================\ | /=====================\ | |||
| H Payload Convergence H--+ | H Payload Convergence H--+ | |||
| H---------------------H | +--------------------------------+ | H---------------------H | +--------------------------------+ | |||
| H Timing H--------->| RTP | | H Timing H--------->| RTP | | |||
| H---------------------H | +--------------------------------+ | H---------------------H | +--------------------------------+ | |||
| H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc | | H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc | | |||
| \=====================/ | +--------------------------------+ | \=====================/ | +--------------------------------+ | |||
| | PW Demultiplexer |----+ | PWE3 Payload Type Identifier | | | PW Demultiplexer |--------->| PW Label | | |||
| +---------------------+ | | +--------------------------------+ | +---------------------+ | +--------------------------------+ | |||
| | PSN Convergence |--+ +---->| PW Label | | | PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap| | |||
| +---------------------+ +--------------------------------+ | +---------------------+ | +--------------------------------+ | |||
| | PSN |--------->| Outer Label or MPLS-in-IP encap| | | PSN |-----+ | |||
| +---------------------+ +--------------------------------+ | +---------------------+ | |||
| | Data-link | | | Data-link | | |||
| +---------------------+ | +---------------------+ | |||
| | Physical | | | Physical | | |||
| +---------------------+ | +---------------------+ | |||
| Figure 11: PWE3 over an MPLS PSN using a control word | Figure 11: PWE3 over an MPLS PSN using a control word | |||
| Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An | Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An | |||
| inner MPLS label is used to provide the PW demultiplexing function. | inner MPLS label is used to provide the PW demultiplexing function. | |||
| A control word is used to carry most of the information needed by the | A control word is used to carry most of the information needed by the | |||
| PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact | PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact | |||
| format. The flags in the control word provide the necessary payload | format. The flags in the control word provide the necessary payload | |||
| convergence. A sequence field provides support for both in-order | convergence. A sequence field provides support for both in-order | |||
| payload delivery and (supported by a fragmentation control method) a | payload delivery and (supported by a fragmentation control method) a | |||
| PSN fragmentation service within the PSN Convergence Layer. Ethernet | PSN fragmentation service within the PSN Convergence Layer. Ethernet | |||
| pads all frames to a minimum size of 64 bytes. The MPLS header does | pads all frames to a minimum size of 64 bytes. The MPLS header does | |||
| not include a length indicator. Therefore to allow PWE3 to be carried | not include a length indicator. Therefore to allow PWE3 to be carried | |||
| in MPLS to correctly pass over an Ethernet data-link, a length | in MPLS to correctly pass over an Ethernet data-link, a length | |||
| correction field is needed in the control word. Where the design of | correction field is needed in the control word. As with an IP PSN, | |||
| the control word would alias an IP packet, a PWE3 Payload Type | where appropriate, timing is provided by RTP [RFC3550]. | |||
| Identifier (PWE3 PID) should be interposed between the PW label and | ||||
| the control word (see 5.4.4). As with an IP PSN, where appropriate, | ||||
| timing is provided by RTP [RFC3550]. | ||||
| In some networks it may be necessary to carry PWE3 over MPLS over IP. | In some networks it may be necessary to carry PWE3 over MPLS over IP. | |||
| In these circumstances, the PW is encapsulated for carriage over MPLS | In these circumstances, the PW is encapsulated for carriage over MPLS | |||
| as described in this section, and then a method of carrying MPLS over | as described in this section, and then a method of carrying MPLS over | |||
| an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the | an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the | |||
| resultant PW-PDU. | resultant PW-PDU. | |||
| 5.4.3. PW over MPLS Generic Control Word | 5.4.3. PW-IP Packet Discrimination | |||
| To allow accurate packet inspection in an MPLS PSN, and/or to operate | ||||
| correctly over MPLS PSNs that have deployed equal-cost multiple-path | ||||
| load-balancing (ECMP), a PW packet MUST NOT alias an IP packet. IP | ||||
| packets are carried in MPLS label stacks without any protocol | ||||
| identifier. Historic values of the IP version number [RFC791] | ||||
| [RFC1883] are therefore used to distinguish between IP and non-IP | ||||
| MPLS payloads. | ||||
| To disambiguate the PW from an IP flow the PW SHOULD employ either | ||||
| the generic PW control word shown in Figure 12, or a PWE3 PID. Note | ||||
| that an MPLS payload with bits 0..3 = 4 is an IPv4 packet and an MPLS | ||||
| payload with bits 0..3 = 6 is an IPv6 packet. | ||||
| 0 1 2 3 | ||||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |0 0 0 0| Specified by PW Encapsulation | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 12: Generic PW Control Word | ||||
| The PW set-up protocol determines whether a PW uses a control word. | ||||
| When a control word is used, it SHOULD have the following preferred | ||||
| form: | ||||
| 0 1 2 3 | ||||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |0 0 0 0| Flags |FRG| Length | Sequence Number | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 13: MPLS Preferred Control Word | ||||
| The meaning of the fields of the MPLS Preferred Control Word (Figure | ||||
| 13) is as follows: | ||||
| Flags (bits 4 to 7): | ||||
| These bits are available for per payload signaling. Their | ||||
| definition is encapsulation specific. | ||||
| FRG (bits 8 and 9): | ||||
| These bits are used when fragmenting a PW payload. Their use | ||||
| is defined in [FRAG]. When the PW is of a type that will | ||||
| never need payload fragmentation, these bits may be used as | ||||
| general purpose flags. | ||||
| Length (bits 10 to 15): | ||||
| The length field is used to determine the size of a PW | ||||
| payload that might have been padded to the minimum Ethernet | ||||
| MAC frame size during its transit across the PSN. If the | ||||
| MPLS payload (defined as the CW + the PW payload + any | ||||
| additional PW headers is less than 46 bytes, the length MUST | ||||
| be set to the length of the MPLS payload. If the MPLS | ||||
| payload is between 46 bytes and 63 bytes the implementation | ||||
| MAY either set to the length to the length of the MPLS | ||||
| payload, or it MAY set it to 0. If the length of the MPLS | ||||
| payload is greater than 63 bytes the length MUST be set to 0. | ||||
| Sequence number (Bit 16 to 31): | ||||
| If the sequence number is not used, it is set to zero by | ||||
| the sender and ignored by the receiver. Otherwise it | ||||
| specifies the sequence number of a packet. A circular list | ||||
| of sequence numbers is used. A sequence number takes a value | ||||
| from 1 to 65535 (2**16-1). If the payload is an OAM packet | ||||
| the sequence number MAY be used to mark the position in the | ||||
| sequence, in which case it has the same value as the last | ||||
| data PDU sent. The use of the sequence number is optional | ||||
| for OAM payloads. | ||||
| 5.4.4. PWE3 Payload Type Identifier | ||||
| If technical considerations result in a PW control word that may | ||||
| alias an IP packet, the control word SHOULD be preceded by an PWE3 | ||||
| payload type identifier (PWE3 PID). | ||||
| The PWE3 PID is defined as follows: | ||||
| 0 1 2 3 | ||||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |0 0 0 1| reserved = 0 | PA | Protocol ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | As defined by PPP DLL protocol definition | | ||||
| | | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 14: PWE3 PID | ||||
| The meaning of the fields of the PWE3 PID (Figure 14) is as follows: | ||||
| PA protocol authority for the user plane or the control plane | ||||
| protocol ID | ||||
| 0 = PPP DLL | ||||
| 1-15 = Reserved | ||||
| Protocol ID | For MPLS PSNs there is an additional constraint on the PW packet | |||
| Protocol ID following the format defined by the protocol | format. In order to facilitate proper functioning of label switched | |||
| authority identified in PA. | routers that detect IP packets based on the initial four bits of the | |||
| packet content, these bits in PW packets must not be the same as an | ||||
| IP version number in current use. | ||||
| Bits 4 to 11 inclusive are reserved for future use and must be zero. | The use of this field for PWs is work in progress. | |||
| .sp | ||||
| 6. PW Demultiplexer Layer and PSN Requirements | 6. PW Demultiplexer Layer and PSN Requirements | |||
| PWE3 places three service requirements on the protocol layers used to | PWE3 places three service requirements on the protocol layers used to | |||
| carry it across the PSN: | carry it across the PSN: | |||
| o Multiplexing | o Multiplexing | |||
| o Fragmentation | o Fragmentation | |||
| o Length and Delivery | o Length and Delivery | |||
| 6.1 Multiplexing | 6.1 Multiplexing | |||
| The purpose of the PW Demultiplexer Layer is to allow multiple PWs to | The purpose of the PW Demultiplexer Layer is to allow multiple PWs to | |||
| be carried in a single tunnel. This minimizes complexity and | be carried in a single tunnel. This minimizes complexity and | |||
| conserves resources. | conserves resources. | |||
| Some types of native service are capable of grouping multiple | Some types of native service are capable of grouping multiple | |||
| circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple | circuits into a "trunk", e.g. multiple ATM VCs in a VP, multiple | |||
| Ethernet VLANs on a physical media, or multiple DS0 services within a | Ethernet VLANs on a physical media, or multiple DS0 services within a | |||
| T1 or E1. A PW MAY interconnect two end-trunks. That trunk would | T1 or E1. A PW may interconnect two end-trunks. That trunk would | |||
| have a single multiplexing identifier. | have a single multiplexing identifier. | |||
| When a MPLS label is used as a PW Demultiplexer setting of the TTL | When a MPLS label is used as a PW Demultiplexer setting of the TTL | |||
| value [RFC3032] in the PW label is application specific, however in a | value [RFC3032] in the PW label is application specific, however in a | |||
| strict point to point application the TTL SHOULD be set to 2. | strict point to point application the TTL should be set to 2. | |||
| 6.2 Fragmentation | 6.2 Fragmentation | |||
| If the PSN provides a fragmentation and reassembly service of | If the PSN provides a fragmentation and reassembly service of | |||
| adequate performance, it MAY be used to obtain an effective MTU that | adequate performance, it may be used to obtain an effective MTU that | |||
| is large enough to transport the PW PDUs. See Section 5.3 for a full | is large enough to transport the PW PDUs. See Section 5.3 for a full | |||
| discussion of the PW fragmentation issues. | discussion of the PW fragmentation issues. | |||
| 6.3 Length and Delivery | 6.3 Length and Delivery | |||
| PDU delivery to the egress PE is the function of the PSN Layer. | PDU delivery to the egress PE is the function of the PSN Layer. | |||
| If the underlying PSN does not provide all the information necessary | If the underlying PSN does not provide all the information necessary | |||
| to determine the length of a PW-PDU, the Encapsulation Layer MUST | to determine the length of a PW-PDU, the Encapsulation Layer must | |||
| provide it. | provide it. | |||
| 6.4 PW-PDU Validation | 6.4 PW-PDU Validation | |||
| It is a common practice to use an error detection mechanism such as a | It is a common practice to use an error detection mechanism such as a | |||
| CRC or similar mechanism to assure end-to-end integrity of frames. | CRC or similar mechanism to assure end-to-end integrity of frames. | |||
| The PW service-specific mechanisms MUST define whether the packet's | The PW service-specific mechanisms must define whether the packet's | |||
| checksum shall be preserved across the PW, or be removed from PE- | checksum shall be preserved across the PW, or be removed from PE- | |||
| bound PDUs and then be re-calculated for insertion in CE-bound data. | bound PDUs and then be re-calculated for insertion in CE-bound data. | |||
| The former approach saves work, while the latter saves bandwidth. For | The former approach saves work, while the latter saves bandwidth. For | |||
| a given implementation the choice may be dictated by hardware | a given implementation the choice may be dictated by hardware | |||
| restrictions, which may not allow the preservation of the checksum. | restrictions, which may not allow the preservation of the checksum. | |||
| For protocols such as ATM and FR, the scope of the checksum is | For protocols such as ATM and FR, the scope of the checksum is | |||
| restricted to a single link. This is because the circuit identifiers | restricted to a single link. This is because the circuit identifiers | |||
| (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are | (e.g. FR DLCI or ATM VPI/VCI) have only local significance and are | |||
| changed on each hop or span. If the circuit identifier (and thus | changed on each hop or span. If the circuit identifier (and thus | |||
| checksum) were going to change as a part of the PW emulation, it | checksum) were going to change as a part of the PW emulation, it | |||
| would be more efficient to strip and re-calculate the checksum. | would be more efficient to strip and re-calculate the checksum. | |||
| The service specific document for each protocol MUST describe the | The service specific document for each protocol must describe the | |||
| validation scheme to be used. | validation scheme to be used. | |||
| 6.5 Congestion Considerations | 6.5 Congestion Considerations | |||
| The PSN carrying the PW may be subject to congestion. The congestion | The PSN carrying the PW may be subject to congestion. The congestion | |||
| characteristics will vary with the PSN type, the network architecture | characteristics will vary with the PSN type, the network architecture | |||
| and configuration, and the loading of the PSN. | and configuration, and the loading of the PSN. | |||
| Where the traffic carried over the PW is known to be TCP friendly | Where the traffic carried over the PW is known to be TCP friendly | |||
| (by, for example, packet inspection), packet discard in the PSN will | (by, for example, packet inspection), packet discard in the PSN will | |||
| trigger the necessary reduction in offered load, and no additional | trigger the necessary reduction in offered load, and no additional | |||
| congestion avoidance action is necessary. | congestion avoidance action is necessary. | |||
| If the PW is operating over a PSN that provides enhanced delivery, | If the PW is operating over a PSN that provides enhanced delivery, | |||
| the PEs SHOULD monitor packet loss to ensure that the service that | the PEs should monitor packet loss to ensure that the service that | |||
| was requested is actually being delivered. If it is not, then the PE | was requested is actually being delivered. If it is not, then the PE | |||
| SHOULD assume that the PSN is providing a best-effort service, and | should assume that the PSN is providing a best-effort service, and | |||
| SHOULD use the best-effort service congestion avoidance measures | should use the best-effort service congestion avoidance measures | |||
| described below. | described below. | |||
| If best-effort service is being used and the traffic is not known to | If best-effort service is being used and the traffic is not known to | |||
| be TCP friendly, the PEs SHOULD monitor packet loss to ensure that | be TCP friendly, the PEs should monitor packet loss to ensure that | |||
| the packet loss rate is within acceptable parameters. Packet loss is | the packet loss rate is within acceptable parameters. Packet loss is | |||
| considered acceptable if a TCP flow across the same network path and | considered acceptable if a TCP flow across the same network path and | |||
| experiencing the same network conditions would achieve an average | experiencing the same network conditions would achieve an average | |||
| throughput, measured on a reasonable timescale, that is not less than | throughput, measured on a reasonable timescale, that is not less than | |||
| the PW flow is achieving. This condition can be satisfied by | the PW flow is achieving. This condition can be satisfied by | |||
| implementing a rate-limiting measure in the NSP, or by shutting down | implementing a rate-limiting measure in the NSP, or by shutting down | |||
| one or more PWs. The choice of which approach to use depends upon | one or more PWs. The choice of which approach to use depends upon | |||
| the type of traffic being carried. Where congestion is avoided by | the type of traffic being carried. Where congestion is avoided by | |||
| shutting down a PW, a suitable mechanism MUST be provided to prevent | shutting down a PW, a suitable mechanism must be provided to prevent | |||
| it immediately returning to service, causing a series of congestion | it immediately returning to service, causing a series of congestion | |||
| pulses. | pulses. | |||
| The comparison to TCP cannot be specified exactly, but is intended as | The comparison to TCP cannot be specified exactly, but is intended as | |||
| an "order-of-magnitude" comparison in timescale and throughput. The | an "order-of-magnitude" comparison in timescale and throughput. The | |||
| timescale on which TCP throughput is measured is the round-trip time | timescale on which TCP throughput is measured is the round-trip time | |||
| of the connection. In essence, this requirement states that it is not | of the connection. In essence, this requirement states that it is not | |||
| acceptable to deploy an application (using PWE3 or any other | acceptable to deploy an application (using PWE3 or any other | |||
| transport protocol) on the best-effort Internet which consumes | transport protocol) on the best-effort Internet which consumes | |||
| bandwidth arbitrarily and does not compete fairly with TCP within an | bandwidth arbitrarily and does not compete fairly with TCP within an | |||
| order of magnitude. One method of determining an acceptable PW | order of magnitude. One method of determining an acceptable PW | |||
| bandwidth is described in [RFC3448]. | bandwidth is described in [RFC3448]. | |||
| 7. Control Plane | 7. Control Plane | |||
| This section describes PWE3 control plane services. | This section describes PWE3 control plane services. | |||
| 7.1 Set-up or Teardown of Pseudo-Wires | 7.1 Set-up or Teardown of Pseudo-Wires | |||
| A PW MUST be set up before an emulated service can be established, | A PW must be set up before an emulated service can be established, | |||
| and MUST be torn down when an emulated service is no longer needed. | and must be torn down when an emulated service is no longer needed. | |||
| Set up or teardown of a PW can be triggered by an operator command, | Set up or teardown of a PW can be triggered by an operator command, | |||
| from the management plane of a PE, by signaling (i.e., set-up or | from the management plane of a PE, by signaling (i.e., set-up or | |||
| teardown) of an AC, e.g., an ATM SVC, or by an auto-discovery | teardown) of an AC, e.g., an ATM SVC, or by an auto-discovery | |||
| mechanism. | mechanism. | |||
| During the set-up process, the PEs need to exchange some information | During the set-up process, the PEs need to exchange some information | |||
| (e.g. learn each other's capabilities). The tunnel signaling | (e.g. learn each other's capabilities). The tunnel signaling | |||
| protocol MAY be extended to provide mechanisms to enable the PEs to | protocol may be extended to provide mechanisms to enable the PEs to | |||
| exchange all necessary information on behalf of the PW. | exchange all necessary information on behalf of the PW. | |||
| Manual configuration of PWs can be considered a special kind of | Manual configuration of PWs can be considered a special kind of | |||
| signaling, and is allowed. | signaling, and is allowed. | |||
| 7.2 Status Monitoring | 7.2 Status Monitoring | |||
| Some native services have mechanisms for status monitoring. For | Some native services have mechanisms for status monitoring. For | |||
| example, ATM supports OAM for this purpose. For such services, the | example, ATM supports OAM for this purpose. For such services, the | |||
| corresponding emulated services MUST specify how to perform status | corresponding emulated services must specify how to perform status | |||
| monitoring. | monitoring. | |||
| 7.3 Notification of Pseudo-wire Status Changes | 7.3 Notification of Pseudo-wire Status Changes | |||
| 7.3.1. Pseudo-wire Up/Down Notification | 7.3.1. Pseudo-wire Up/Down Notification | |||
| If a native service REQUIRES bi-directional connectivity, the | If a native service REQUIRES bi-directional connectivity, the | |||
| corresponding emulated service can only be signaled as being up when | corresponding emulated service can only be signaled as being up when | |||
| the associated PWs, and PSN tunnels if any, are functional in both | the associated PWs, and PSN tunnels if any, are functional in both | |||
| directions. | directions. | |||
| Because the two CEs of an emulated service are not adjacent, a | Because the two CEs of an emulated service are not adjacent, a | |||
| failure may occur at a place such that one or both physical links | failure may occur at a place such that one or both physical links | |||
| between the CEs and PEs remain up. For example, in Figure 2, if the | between the CEs and PEs remain up. For example, in Figure 2, if the | |||
| physical link between CE1 and PE1 fails, the physical link between | physical link between CE1 and PE1 fails, the physical link between | |||
| CE2 and PE2 will not be affected and will remain up. Unless CE2 is | CE2 and PE2 will not be affected and will remain up. Unless CE2 is | |||
| notified about the remote failure, it will continue to send traffic | notified about the remote failure, it will continue to send traffic | |||
| over the emulated service to CE1. Such traffic will be discarded at | over the emulated service to CE1. Such traffic will be discarded at | |||
| PE1. Some native services have failure notification so that when the | PE1. Some native services have failure notification so that when the | |||
| services fail, both CEs will be notified. For such native services, | services fail, both CEs will be notified. For such native services, | |||
| the corresponding PWE3 service MUST provide a failure notification | the corresponding PWE3 service must provide a failure notification | |||
| mechanism. | mechanism. | |||
| Similarly, if a native service has notification mechanisms so that | Similarly, if a native service has notification mechanisms so that | |||
| when a network failure is fixed, all the affected services will | when a network failure is fixed, all the affected services will | |||
| change status from "Down" to "Up", the corresponding emulated service | change status from "Down" to "Up", the corresponding emulated service | |||
| MUST provide a similar mechanism for doing so. | must provide a similar mechanism for doing so. | |||
| These mechanisms may already be built into the tunneling protocol. | These mechanisms may already be built into the tunneling protocol. | |||
| For example, the L2TP control protocol [RFC2661] [L2TPv3] has this | For example, the L2TP control protocol [RFC2661] [L2TPv3] has this | |||
| capability and LDP has the ability to withdraw the corresponding MPLS | capability and LDP has the ability to withdraw the corresponding MPLS | |||
| label. | label. | |||
| 7.3.2. Misconnection and Payload Type Mismatch | 7.3.2. Misconnection and Payload Type Mismatch | |||
| With PWE3, misconnection and payload type mismatch can occur. If a | With PWE3, misconnection and payload type mismatch can occur. If a | |||
| misconnection occurs it can breach the integrity of the system. If a | misconnection occurs it can breach the integrity of the system. If a | |||
| skipping to change at page 36, line 29 ¶ | skipping to change at page 34, line 24 ¶ | |||
| A PW can incur packet loss, corruption, and out-of-order delivery on | A PW can incur packet loss, corruption, and out-of-order delivery on | |||
| the PSN path between the PEs. This can impact the working condition | the PSN path between the PEs. This can impact the working condition | |||
| of an emulated service. For some payload types, packet loss, | of an emulated service. For some payload types, packet loss, | |||
| corruption, and out-of-order delivery can be mapped to either a bit | corruption, and out-of-order delivery can be mapped to either a bit | |||
| error burst, or loss of carrier on the PW. If a native service has | error burst, or loss of carrier on the PW. If a native service has | |||
| some mechanism to deal with bit error, the corresponding PWE3 service | some mechanism to deal with bit error, the corresponding PWE3 service | |||
| should provide a similar mechanism. | should provide a similar mechanism. | |||
| 7.3.4. Other Status Notification | 7.3.4. Other Status Notification | |||
| A PWE3 approach MAY provide a mechanism for other status | A PWE3 approach may provide a mechanism for other status | |||
| notification, if any are needed. | notification, if any are needed. | |||
| 7.3.5. Collective Status Notification | 7.3.5. Collective Status Notification | |||
| Status of a group of emulated services may be affected identically by | Status of a group of emulated services may be affected identically by | |||
| a single network incident. For example, when the physical link (or | a single network incident. For example, when the physical link (or | |||
| sub-network) between a CE and a PE fails, all the emulated services | sub-network) between a CE and a PE fails, all the emulated services | |||
| that go through that link (or sub-network) will fail. It is likely | that go through that link (or sub-network) will fail. It is likely | |||
| that there exists a group of emulated services that all terminate at | that there exists a group of emulated services that all terminate at | |||
| a remote CE. There may also be multiple such CEs affected by the | a remote CE. There may also be multiple such CEs affected by the | |||
| failure. Therefore, it is desirable that a single notification | failure. Therefore, it is desirable that a single notification | |||
| message be used to notify failure of the whole group of emulated | message be used to notify failure of the whole group of emulated | |||
| services. | services. | |||
| A PWE3 approach MAY provide some mechanism for notifying status | A PWE3 approach may provide some mechanism for notifying status | |||
| changes of a group of emulated circuits. One possible method is to | changes of a group of emulated circuits. One possible method is to | |||
| associate each emulated service with a group ID when the PW for that | associate each emulated service with a group ID when the PW for that | |||
| emulated service is set up. Multiple emulated services can then be | emulated service is set up. Multiple emulated services can then be | |||
| grouped by associating them with the same group ID. In status | grouped by associating them with the same group ID. In status | |||
| notification, that group ID can be used to refer all the emulated | notification, that group ID can be used to refer all the emulated | |||
| services in that group. The group ID mechanism should be a mechanism | services in that group. The group ID mechanism should be a mechanism | |||
| provided by the underlying tunnel signaling protocol. | provided by the underlying tunnel signaling protocol. | |||
| 7.4 Keep-alive | 7.4 Keep-alive | |||
| If a native service has a keep-alive mechanism, the corresponding | If a native service has a keep-alive mechanism, the corresponding | |||
| emulated service MUST provide a mechanism to propagate this across | emulated service must provide a mechanism to propagate this across | |||
| the PW. An approach following the principle of minimum intervention | the PW. An approach following the principle of minimum intervention | |||
| would be to transparently transport keep-alive messages over the PW. | would be to transparently transport keep-alive messages over the PW. | |||
| However, to accurately reproduce the semantics of the native | However, to accurately reproduce the semantics of the native | |||
| mechanism, some PWs MAY REQUIRE an alternative approach, such as | mechanism, some PWs may require an alternative approach, such as | |||
| piggy-backing on the PW signaling mechanism. | piggy-backing on the PW signaling mechanism. | |||
| 7.5 Handling Control Messages of the Native Services | 7.5 Handling Control Messages of the Native Services | |||
| Some native services use control messages for circuit maintenance. | Some native services use control messages for circuit maintenance. | |||
| These control messages MAY be in-band, e.g. Ethernet flow control, | These control messages may be in-band, e.g. Ethernet flow control, | |||
| ATM performance management, or TDM tone signaling, or they MAY be | ATM performance management, or TDM tone signaling, or they may be | |||
| out-of-band, e.g. the signaling VC of an ATM VP, or TDM CCS | out-of-band, e.g. the signaling VC of an ATM VP, or TDM CCS | |||
| signaling. | signaling. | |||
| From the principle of minimum intervention, it is desirable that the | From the principle of minimum intervention, it is desirable that the | |||
| PEs participate as little as possible in the signaling and | PEs participate as little as possible in the signaling and | |||
| maintenance of the native services. This principle SHOULD NOT, | maintenance of the native services. This principle should not, | |||
| however, override the need to satisfactorily emulate the native | however, override the need to satisfactorily emulate the native | |||
| service. | service. | |||
| If control messages are passed through, it may be desirable to send | If control messages are passed through, it may be desirable to send | |||
| them using either a higher priority or a reliable channel provided by | them using either a higher priority or a reliable channel provided by | |||
| the PW Demultiplexer layer. See PWE3 Channel Types. | the PW Demultiplexer layer. See PWE3 Channel Types. | |||
| 8. Management and Monitoring | 8. Management and Monitoring | |||
| This section describes the management and monitoring architecture for | This section describes the management and monitoring architecture for | |||
| skipping to change at page 38, line 4 ¶ | skipping to change at page 35, line 45 ¶ | |||
| The PE should report the status of the interface and tabulate | The PE should report the status of the interface and tabulate | |||
| statistics that help monitor the state of the network, and to help | statistics that help monitor the state of the network, and to help | |||
| with measurement of service level agreements (SLAs). Typical counters | with measurement of service level agreements (SLAs). Typical counters | |||
| include: | include: | |||
| o Counts of PW-PDUs sent and received, with and without errors. | o Counts of PW-PDUs sent and received, with and without errors. | |||
| o Counts of sequenced PW-PDUs lost. | o Counts of sequenced PW-PDUs lost. | |||
| o Counts of service PDUs sent and received over the PSN, with | o Counts of service PDUs sent and received over the PSN, with | |||
| and without errors (non-TDM). | and without errors (non-TDM). | |||
| o Service-specific interface counts. | o Service-specific interface counts. | |||
| o One way delay and delay variation. | o One way delay and delay variation. | |||
| These counters would be contained in a PW-specific MIB, and they | These counters would be contained in a PW-specific MIB, and they | |||
| should not replicate existing MIB counters. | should not replicate existing MIB counters. | |||
| 8.2 PW SNMP MIB Architecture | 8.2 PW SNMP MIB Architecture | |||
| This section describes the general architecture for SNMP MIBs used to | This section describes the general architecture for SNMP MIBs used to | |||
| manage PW services and the underlying PSN. The intent here is to | manage PW services and the underlying PSN. The intent here is to | |||
| provide a clear picture of how all of the pertinent MIBs fit together | provide a clear picture of how all of the pertinent MIBs fit together | |||
| to form a cohesive management framework for deploying PWE3 services. | to form a cohesive management framework for deploying PWE3 services. | |||
| Note that the names of MIB modules used below are suggestions, and do | ||||
| not necessarily require the actual modules used to realize the | ||||
| components in the architecture to be named exactly so. | ||||
| 8.2.1. MIB Layering | 8.2.1. MIB Layering | |||
| The SNMP MIBs created for PWE3 should fit the architecture shown in | The SNMP MIBs created for PWE3 should fit the architecture shown in | |||
| Figure 15. | Figure 15. The architecture provides a layered modular model into | |||
| which any supported emulated service can be connected to any | ||||
| supported PSN type. This model fosters reuse of as much functionality | ||||
| as possible. For instance, the emulated service layer MIB modules do | ||||
| not redefine the existing emulated service MIB module; rather, they | ||||
| only associate it with the pseudowires used to carry the emulated | ||||
| service over the configured PSN. In this way, the PWE3 MIB | ||||
| architecture follows the overall PWE3 archiecture. | ||||
| +-----------+ +-----------+ +-----------+ | The archtecture does allow for the joining of unsupported emulated | |||
| Service | CEM | | Ethernet | | ATM | | service or PSN types by simply defining additional MIB modules to | |||
| Layer |Service MIB| |Service MIB| ... |Service MIB| | associate these new types with existing ones. These new modules can | |||
| +-----------+ +-----------+ +-----------+ | subsequently be standardized. Note that there is a separate MIB | |||
| \ | / | module for each emulated service as well as one for each underlying | |||
| \ | / | PSN. These MIB modules may be used in various combinations as | |||
| - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - | needed. | |||
| \ | / | ||||
| +-------------------------------------------+ | ||||
| Generic PW | Generic PW MIBs | | ||||
| Layer +-------------------------------------------+ | ||||
| / \ | ||||
| - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - | ||||
| / \ | ||||
| / \ | ||||
| +-----------+ +-----------+ | ||||
| PSN VC |L2TP VC MIB| |MPLS VC MIB| | ||||
| Layer +-----------+ +-----------+ | ||||
| | | | ||||
| - - - - - - - - - | - - - - - - - - - - - - - - - | - - - | ||||
| | | | ||||
| +-----------+ +-----------+ | ||||
| PSN |L2TP MIB(s)| |MPLS MIB(s)| | ||||
| Layer +-----------+ +-----------+ | ||||
| Figure 15: Relationship of SNMP MIBs | Native | |||
| Service MIBs ... ... ... | ||||
| | | | | ||||
| +-----------+ +-----------+ +-----------+ | ||||
| Service | CEP | | Ethernet | | ATM | | ||||
| Layer |Service MIB| |Service MIB| ... |Service MIB| | ||||
| +-----------+ +-----------+ +-----------+ | ||||
| \ | / | ||||
| \ | / | ||||
| - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - | ||||
| \ | / | ||||
| +-------------------------------------------+ | ||||
| Generic PW | Generic PW MIBs | | ||||
| Layer +-------------------------------------------+ | ||||
| / \ | ||||
| - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - | ||||
| / \ | ||||
| / \ | ||||
| +--------------+ +----------------+ | ||||
| PSN VC |L2TP VC MIB(s)| | MPLS VC MIB(s) | | ||||
| Layer +--------------+ +----------------+ | ||||
| | | | ||||
| Native +-----------+ +-----------+ | ||||
| PSN |L2TP MIB(s)| |MPLS MIB(s)| | ||||
| MIBs +-----------+ +-----------+ | ||||
| Figure 16 shows an example for a SONET PW carried over MPLS. | Figure 15: MIB Module Layering Relationship | |||
| +-----------------+ | Figure 16 shows an example for a SONET PW carried over MPLS Traffic | |||
| | SONET MIB | RFC2558 | Engineering Tunnel and an LDP-signaled LSP. | |||
| +-----------------+ | ||||
| | | ||||
| +-----------------+ | ||||
| Service |SONET Service MIB| pw-cem-mib | ||||
| Layer +-----------------+ | ||||
| - - - - - - - - - - | - - - - - - - - - - - - - - - | ||||
| +-----------------+ | ||||
| Generic PW | Generic PW MIBS | pw-tc-mib | ||||
| Layer +-----------------+ pw-mib | ||||
| - - - - - - - - - - | - - - - - - - - - - - - - - - | ||||
| +-----------------+ | ||||
| PSN VC | MPLS VC MIBS | pw-mpls-mib | ||||
| Layer +-----------------+ | ||||
| - - - - - - - - - - | - - - - - - - - - - - - - - - | ||||
| +-----------------+ | ||||
| PSN | MPLS MIBs | mpls-te-mib | ||||
| Layer +-----------------+ mpls-lsr-mib | ||||
| Figure 16: Service-specific Example for MIBs | +-----------------+ | |||
| | SONET MIB | RFC2558 | ||||
| +-----------------+ | ||||
| | | ||||
| +------------------------------+ | ||||
| Service | Circuit Emulation Service MIB| | ||||
| Layer +------------------------------+ | ||||
| - - - - - - - - - - - - - | - - - - - - - - - - - - - | ||||
| +-----------------+ | ||||
| Generic PW | Generic PW MIB | | ||||
| Layer +-----------------+ | ||||
| - - - - - - - - - - - - - | - - - - - - - - - - - - - | ||||
| +-----------------+ | ||||
| PSN VC | MPLS VC MIBs | | ||||
| Layer +-----------------+ | ||||
| | | | ||||
| +-----------------+ +------------------+ | ||||
| | MPLS-TE-STD-MIB | | MPLS-LSR-STD-MIB | | ||||
| +-----------------+ +------------------+ | ||||
| Note that there is a separate MIB for each emulated service as well | Figure 16: SONET PW over MPLS PSN Service-specific Example | |||
| as one for each underlying PSN. These MIBs MAY be used in various | ||||
| combinations as needed. | ||||
| 8.2.2. Service Layer MIBs | 8.2.2. Service Layer MIB Modules | |||
| The first layer is referred to as the Service Layer. It contains | This conceptual layer in the model contains MIB modules used to | |||
| MIBs for PWE3 services such as Ethernet, ATM, circuits and Frame | represent the relationship between emulated PWE3 services such as | |||
| Relay. This layer contains those corresponding MIBs used to mate or | Ethernet, ATM, or Frame Relay and the pseudo-wire used to carry that | |||
| adapt those emulated services to the underlying services. This | service across the PSN. This layer contains those corresponding MIB | |||
| working group should not produce any MIBs for managing the general | modules used to mate or adapt those emulated services to the generic | |||
| service; rather, it should produce just those MIBs that are used to | pseudo-wire representation, which are represented in the "Generic PW | |||
| interface or adapt the emulated service onto the PWE3 management | MIB" functional block in Figure 16 above. This working group should | |||
| framework. For example, the standard SONET MIB [RFC2558] is designed | not produce any MIB modules for managing the general service; rather, | |||
| and maintained by another working group. Also, the SONET MIB is | it should produce just those modules that are used to interface or | |||
| designed to manage the native service without PW emulation. Since | adapt the emulated service onto the PWE3 management framework as | |||
| the PWE3 working group is chartered to produce the corresponding | shown above. For example, the standard SONET-MIB [RFC2558] is | |||
| adaptation MIB, in this case, it would produce the PW-CEM-MIB | designed and maintained by another working group. The SONET-MIB is | |||
| [PWMPLSMIB] that would be used to adapt SONET services to the | designed to manage the native service without PW emulation. However, | |||
| underlying PSN that carries the PWE3 service. | since the PWE3 working group is chartered to produce standards which | |||
| show how to emulate existing technologies such as SONET/SDH over | ||||
| pseudo-wires rather than re-inventing those modules. | ||||
| 8.2.3. Generic PW MIBs | 8.2.3. Generic PW MIB Modules | |||
| The second layer is referred to as the Generic PW Layer. This layer | The middle layer in the architecture is referred to as the Generic PW | |||
| is composed of two MIBs: the PWE-TC-MIB [PWTCMIB] and the PWE-MIB | Layer. MIB in this layer are responsible for providing pseudo-wire | |||
| [PWMIB]. These MIBs are responsible for providing general PWE3 | specific counters and service models used for monitoring and | |||
| counters and service models used for monitoring and configuration of | configuration of PWE3 services over any supported PSN service. That | |||
| PWE3 services over any supported PSN service. That is, this MIB | is, this layer provides a general model of PWE3 abstraction for | |||
| provides a general model of PWE3 abstraction for management purposes. | management purposes. This MIB is used to interconnect the MIB modules | |||
| This MIB is used to interconnect the Service Layer MIBs to the PSN VC | residing in the Service Layer to the PSN VC Layer MIBs (see section | |||
| Layer MIBs. The latter will be described in the next section. This | 8.2.4). | |||
| layer also provides the PW-TC-MIB [PWTCMIB]. This MIB contains | ||||
| common SMI textual conventions [RFC1902] that MAY be used by any PW | ||||
| MIB. | ||||
| 8.2.4. PSN VC Layer MIBs | 8.2.4. PSN VC Layer MIB Modules | |||
| The third layer in the PWE3 management architecture is referred to as | The third layer in the PWE3 management architecture is referred to as | |||
| the PSN VC layer. This layer is comprised of MIBs that are | the PSN VC Layer. It is comprised of MIBs that are specifically | |||
| specifically designed to interface general PWE3 services (VCs) onto | designed to associate pseudo-wires onto those underlying PSN | |||
| those underlying PSN services. In general this means that the MIB | transport technologies that carry the pseudo-wire payloads across the | |||
| provides a means with which an operator can map the PW service onto | PSN. In general this means that the MIB module provides a mapping | |||
| the native PSN service. For example, in the case of MPLS, it is | between the emulated service that is mapped to the pseudo-wire via | |||
| required that the general VC service be layered onto MPLS LSPs or | the Service Layer and Generic PW MIB Layer onto the native PSN | |||
| Traffic Engineered (TE) Tunnels [RFC3031]. In this case, the PW- | service. For example, in the case of MPLS for example, it is required | |||
| MPLS-MIB [PWMPLSMIB] was created to adapt the general PWE3 circuit | that the general VC service be mapped into MPLS LSPs via the MPLS- | |||
| services onto MPLS. Like the Service Layer described above the PWE3 | LSR-STD-MIB [LSRMIB] or Traffic Engineered (TE) Tunnels via the | |||
| working group should produce these MIBs. | MPLS-TE-STD-MIB [TEMIB]. In addition, the MPLS-LDP-STD-MIB [LDPMIB] | |||
| may be used to reveal the MPLS labels that are distributed over the | ||||
| 8.2.5. PSN Layer MIBs | MPLS PSN in order to maintain the PW service. As with the native | |||
| service MIB modules described earlier, the MIB modules used to manage | ||||
| The fourth and final layer in the PWE3 management architecture is | the native PSN services are produced by other working groups that | |||
| referred to as the PSN layer. This layer is comprised of those MIBs | design and specify the native PSN services. These MIBs should contain | |||
| that control the PSN service-specific services. For example, in the | the appropriate mechanisms for monitoring and configuring the PSN | |||
| case of the MPLS [RFC3031] PSN service, the MPLS-LSR-MIB [LSRMIB] and | service such that the emulated PWE3 service will function correctly. | |||
| the MPLS-TE-MIB [TEMIB] are used to interface the general PWE3 VC | ||||
| services onto native MPLS LSPs and/or TE tunnels to carry the | ||||
| emulated services. In addition, the MPLS-LDP-MIB [LDPMIB] MAY be | ||||
| used to reveal the MPLS labels that are distributed over the MPLS PSN | ||||
| in order to maintain the PW service. The MIBs in this layer are | ||||
| produced by other working groups that design and specify the native | ||||
| PSN services. These MIBs should contain the appropriate mechanisms | ||||
| for monitoring and configuring the PSN service such that the emulated | ||||
| PWE3 service will function correctly. | ||||
| 8.3 Connection Verification and Traceroute | 8.3 Connection Verification and Traceroute | |||
| A connection verification mechanism should be supported by PWs. | A connection verification mechanism should be supported by PWs. | |||
| Connection verification as well as other alarm mechanisms can alert | Connection verification as well as other alarm mechanisms can alert | |||
| the operator that a PW has lost its remote connection. The opaque | the operator that a PW has lost its remote connection. The opaque | |||
| nature of a PW means that it is not possible to specify a generic | nature of a PW means that it is not possible to specify a generic | |||
| connection verification or traceroute mechanism that passes this | connection verification or traceroute mechanism that passes this | |||
| status to the CEs over the PW. If connection verification status of | status to the CEs over the PW. If connection verification status of | |||
| the PW is needed by the CE, it MUST be mapped to the native | the PW is needed by the CE, it must be mapped to the native | |||
| connection status method. | connection status method. | |||
| For troubleshooting purposes, it is sometimes desirable to know the | For troubleshooting purposes, it is sometimes desirable to know the | |||
| exact functional path of a PW between PEs. This is provided by the | exact functional path of a PW between PEs. This is provided by the | |||
| traceroute service of the underlying PSN. The opaque nature of the | traceroute service of the underlying PSN. The opaque nature of the | |||
| PW means that this traceroute information is only available within | PW means that this traceroute information is only available within | |||
| the provider network, e.g., at the PEs. | the provider network, e.g., at the PEs. | |||
| 9. IANA considerations | 9. IANA considerations | |||
| Sections 5.4.3 and 5.4.4 discuss the issue of aliasing between PW and | IANA considerations will be identified in the PWE3 documents that | |||
| IP packets on an MPLS PSN. This aliasing is resolved by using two | define the PWE3 encapsulation, control and management protocols. | |||
| historic IP version numbers to indicate that the payload is an MPLS | ||||
| preferred control word, or a PWE3 PID. The IP version number | ||||
| registry needs to be updated to allocate IP version number 0 | ||||
| (currently reserved) to MPLS preferred control word, and IP version | ||||
| number 1 (currently unassigned) to PWE3 PID. | ||||
| 10. Security Considerations | 10. Security Considerations | |||
| PWE3 provides no means of protecting the integrity, confidentiality | PWE3 provides no means of protecting the integrity, confidentiality | |||
| or delivery of the native data units. The use of PWE3 can therefore | or delivery of the native data units. The use of PWE3 can therefore | |||
| expose a particular environment to additional security threats. | expose a particular environment to additional security threats. | |||
| Assumptions that might be appropriate when all communicating systems | Assumptions that might be appropriate when all communicating systems | |||
| are interconnected via a point to point or circuit-switched network | are interconnected via a point to point or circuit-switched network | |||
| may no longer hold when they are interconnected using an emulated | may no longer hold when they are interconnected using an emulated | |||
| wire carried over some types of PSN. It is outside the scope of this | wire carried over some types of PSN. It is outside the scope of this | |||
| skipping to change at page 42, line 15 ¶ | skipping to change at page 40, line 36 ¶ | |||
| Ethernet connected via a PW. | Ethernet connected via a PW. | |||
| Exploitation of vulnerabilities from within the PSN may be directed | Exploitation of vulnerabilities from within the PSN may be directed | |||
| to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel | to the PW Tunnel end-point so that PW Demultiplexer and PSN tunnel | |||
| services are disrupted. Controlling PSN access to the PW Tunnel | services are disrupted. Controlling PSN access to the PW Tunnel | |||
| end-point is one way to protect against this. By restricting PW | end-point is one way to protect against this. By restricting PW | |||
| Tunnel end-point access to legitimate remote PE sources of traffic, | Tunnel end-point access to legitimate remote PE sources of traffic, | |||
| the PE may reject traffic that would interfere with the PW | the PE may reject traffic that would interfere with the PW | |||
| Demultiplexing and PSN tunnel services. | Demultiplexing and PSN tunnel services. | |||
| Protection mechanisms MUST also address the spoofing of tunneled PW | Protection mechanisms must also address the spoofing of tunneled PW | |||
| data. The validation of traffic addressed to the PW Demultiplexer | data. The validation of traffic addressed to the PW Demultiplexer | |||
| end-point is paramount in ensuring integrity of PW encapsulation. | end-point is paramount in ensuring integrity of PW encapsulation. | |||
| Security protocols such as IPSec [RFC2401] MAY be used by the PW | Security protocols such as IPSec [RFC2401] may be used by the PW | |||
| Demultiplexer Layer in order to maintain the integrity of the PW by | Demultiplexer Layer in order to maintain the integrity of the PW by | |||
| authenticating data between the PW Demultiplexer End-points. | authenticating data between the PW Demultiplexer End-points. | |||
| IPSec MAY provide authentication, integrity, non-repudiation, and | IPSec may provide authentication, integrity, and confidentiality of | |||
| confidentiality of data transferred between two PEs. It cannot | data transferred between two PEs. It cannot provide the equivalent | |||
| provide the equivalent services to the native service. | services to the native service. | |||
| Based on the type of data being transferred, the PW MAY indicate to | Based on the type of data being transferred, the PW may indicate to | |||
| the PW Demultiplexer Layer that enhanced security services are | the PW Demultiplexer Layer that enhanced security services are | |||
| required. The PW Demultiplexer Layer MAY define multiple protection | required. The PW Demultiplexer Layer may define multiple protection | |||
| profiles based on the requirements of the PW emulated service. CE- | profiles based on the requirements of the PW emulated service. CE- | |||
| to-CE signaling and control events emulated by the PW and some data | to-CE signaling and control events emulated by the PW and some data | |||
| types may require additional protection mechanisms. Alternatively, | types may require additional protection mechanisms. Alternatively, | |||
| the PW Demultiplexer Layer may use peer authentication for every PSN | the PW Demultiplexer Layer may use peer authentication for every PSN | |||
| packet to prevent spoofed native data units from being sent to the | packet to prevent spoofed native data units from being sent to the | |||
| destination CE. | destination CE. | |||
| The unlimited transformation capability of the NSP may be perceived | The unlimited transformation capability of the NSP may be perceived | |||
| as a security risk. In practise the type of operation that the NSP | as a security risk. In practise the type of operation that the NSP | |||
| may perform will be limited to those that have been implemented in | may perform will be limited to those that have been implemented in | |||
| the data path. The access controls that are in place in the PE to | the data path. A PE designed and managed to best current practise | |||
| protect and validate its configuration will be sufficient to ensure | will have controls in place that protect and validate its | |||
| that the NSP performs as expected. | configuration and these will be sufficient to ensure that the NSP | |||
| behaves as expected. | ||||
| Acknowledgments | Acknowledgments | |||
| We thank: Sasha Vainshtein for his work on Native Service Processing | We thank: Sasha Vainshtein for his work on Native Service Processing | |||
| and advice on bit-stream over PW services. Thomas K. Johnson for his | and advice on bit-stream over PW services. Thomas K. Johnson for his | |||
| work on the background and motivation for PWs. | work on the background and motivation for PWs. | |||
| We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar | We also thank: Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar | |||
| Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John | Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John | |||
| Rutemiller, Scott Wainner and David Zelig for their comments and | Rutemiller, Scott Wainner and David Zelig for their comments and | |||
| contributions. | contributions. | |||
| Normative References | Normative References | |||
| Internet-drafts are works in progress available from | Internet-drafts are works in progress available from | |||
| <http://www.ietf.org/internet-drafts/> | <http://www.ietf.org/internet-drafts/> | |||
| [FRAG] Malis and Townsley, "PWE3 Fragmentation and | [FRAG] Malis and Townsley, "PWE3 Fragmentation and | |||
| Reassembly", <draft-ietf-pwe3-fragmentation-02.txt>, | Reassembly", <draft-ietf-pwe3-fragmentation-05.txt>, | |||
| work in progress, June 2003. | work in progress, February 2004. | |||
| [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, | [L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau, | |||
| et. al. <draft-ietf-l2tpext-l2tp-base-08.txt>, work | et. al. <draft-ietf-l2tpext-l2tp-base-11.txt>, work | |||
| in progress, June 2003. | in progress, October 2003. | |||
| [RFC768] RFC-768: User Datagram Protocol, J. Postel, Aug-28-1980. | ||||
| [RFC791] RFC-791: DARPA Internet Program, Protocol Specification, | [RFC791] RFC-791: DARPA Internet Program, Protocol Specification, | |||
| ISI, September 1981. | ISI, September 1981. | |||
| [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), | [RFC1883] RFC-1883: Internet Protocol, Version 6 (IPv6), | |||
| S. Deering, et al, December 1995 | S. Deering, et al, December 1995 | |||
| [RFC1902] RFC-1902: Structure of Management Information for | [RFC1902] RFC-1902: Structure of Management Information for | |||
| Version 2 of the Simple Network Management Protocol | Version 2 of the Simple Network Management Protocol | |||
| (SNMPv2), Case et al, January 1996. | (SNMPv2), Case et al, January 1996. | |||
| skipping to change at page 44, line 30 ¶ | skipping to change at page 43, line 8 ¶ | |||
| <http://www.ietf.org/internet-drafts/> | <http://www.ietf.org/internet-drafts/> | |||
| [DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing | [DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing | |||
| structure, channel coding and modulation for digital | structure, channel coding and modulation for digital | |||
| terrestrial television (DVB-T), European | terrestrial television (DVB-T), European | |||
| Telecommunications Standards Institute (ETSI) | Telecommunications Standards Institute (ETSI) | |||
| [LDPMIB] Cucchiara, J., Sjostrand, H., and Luciani, J., | [LDPMIB] Cucchiara, J., Sjostrand, H., and Luciani, J., | |||
| "Definitions of Managed Objects for the Multiprotocol | "Definitions of Managed Objects for the Multiprotocol | |||
| Label Switching, Label Distribution Protocol (LDP)", | Label Switching, Label Distribution Protocol (LDP)", | |||
| <draft-ietf-mpls-ldp-mib-11.txt>, work in progress, | <draft-ietf-mpls-ldp-mib-14.txt>, work in progress, | |||
| June 2003. | November 2003. | |||
| [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-10.txt>, work in progress, | <draft-ietf-mpls-lsr-mib-14.txt>, work in progress, | |||
| June 2003. | November 2003. | |||
| [PPPoL2TP] PPP Tunneling Using Layer Two Tunneling Protocol, | ||||
| J Lau et al. <draft-ietf-l2tpext-l2tp-ppp-02.txt>, | ||||
| work in progress, June 2002. | ||||
| [PWMIB] Zelig et al, "Pseudo Wire (PW) Management Information | ||||
| Base Using SMIv2", <draft-ietf-pwe3-pw-mib-01.txt>, | ||||
| work in progress, June 2003. | ||||
| [PWTCMIB] Nadeau et al, "Definitions for Textual Conventions and | ||||
| OBJECT-IDENTITIES for Pseudo-Wires Management" | ||||
| <draft-ietf-pwe3-pw-tc-mib-01.txt>, work in progress, | ||||
| June 2003. | ||||
| [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service | [MPLSIP] Rosen et al, "Encapsulating MPLS in IP or Generic | |||
| Over MPLS (CEM) Management Information Base Using | Routing Encapsulation (GRE)", | |||
| SMIv2", <draft-ietf-pwe3-cep-mib-01.txt>, work in | <draft-ietf-mpls-in-ip-or-gre-07.txt>, work in progress, | |||
| progress, October 2002. | March 2004 | |||
| [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. | [RFC1191] RFC-1191: Path MTU discovery. J.C. Mogul, S.E. Deering. | |||
| [RFC1958] RFC-1958: Architectural Principles of the Internet, | [RFC1958] RFC-1958: Architectural Principles of the Internet, | |||
| B. Carpenter et al. | B. Carpenter et al. | |||
| [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, | [RFC1981] RFC-1981: Path MTU Discovery for IP version 6. J. McCann, | |||
| S. Deering, J. Mogul. | S. Deering, J. Mogul. | |||
| [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based | [RFC2022] RFC-2022: Support for Multicast over UNI 3.0/3.1 based | |||
| skipping to change at page 45, line 30 ¶ | skipping to change at page 43, line 43 ¶ | |||
| S. Knight, M. Shand et. al. | S. Knight, M. Shand et. al. | |||
| [RFC3022] RFC-3022: Traditional IP Network Address Translator | [RFC3022] RFC-3022: Traditional IP Network Address Translator | |||
| (Traditional NAT). P Srisuresh et al. | (Traditional NAT). P Srisuresh et al. | |||
| [RFC3448] RFC3448: TCP Friendly Rate Control (TFRC): Protocol | [RFC3448] RFC3448: TCP Friendly Rate Control (TFRC): Protocol | |||
| Specification, M. Handley et al. January 2003. | Specification, M. Handley et al. January 2003. | |||
| [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-10.txt>, work in progress, | <draft-ietf-mpls-te-mib-14.txt>, work in progress, | |||
| June 2003. | November 2003. | |||
| [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation | [XIAO] Xiao et al, "Requirements for Pseudo-Wire Emulation | |||
| Edge-to-Edge (PWE3)", | Edge-to-Edge (PWE3)", | |||
| (draft-ietf-pwe3-requirements-06.txt), X Xiao et al. | (draft-ietf-pwe3-requirements-08.txt), X Xiao et al. | |||
| work in progress, June 2002. | work in progress, December 2002. | |||
| Editors' Addresses | Editors' Addresses | |||
| Stewart Bryant | Stewart Bryant | |||
| Cisco Systems, | Cisco Systems, | |||
| 250, Longwater, | 250, Longwater, | |||
| Green Park, | Green Park, | |||
| Reading, RG2 6GB, | Reading, RG2 6GB, | |||
| United Kingdom. Email: stbryant@cisco.com | United Kingdom. Email: stbryant@cisco.com | |||
| End of changes. 111 change blocks. | ||||
| 384 lines changed or deleted | 272 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/ | ||||