Internet DRAFT - draft-srinivasan-fr-over-mpls-with-frf-16
draft-srinivasan-fr-over-mpls-with-frf-16
Network Working Group Eswaran Srinivasan, Ed.
Internet Draft Juniper Networks
Expiration Date: May 31, 2013 Luis Tomotaki, Ed.
Verizon
November 30, 2012
Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks with
Multilink Frame Relay UNI/NNI (FRF.16) Endpoints
draft-srinivasan-fr-over-mpls-with-frf-16-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2013.
Abstract
A Frame Relay pseudowire (PW) with Multilink Frame Relay UNI/NNI
(FRF.16) is a mechanism that can be used for transporting the Frame
Relay Protocol Data Units (PDUs) got after reassembling the FRF.16
fragments over a MPLS packet switched network (PSN). The goal of
this document is to describe the encapsulation that is required for
this.
1. Introduction
A Frame Relay pseudowire (PW) with Multilink Frame Relay UNI/NNI
(FRF.16) allows the Frame Relay Protocol Data Units (PDUs) got after
reassembling the FRF.16 fragments to be carried over a MPLS network
to a remote Provider Edge (PE) device.
The remote PE can interface with a Customer Edge (CE) device running
a FRF.16 service or a non-multilink Frame Relay service. Hence,
this approach allows interconnecting two heterogeneous type CE
devices.
In a nutshell, providing this support on a PE will include the
following operations:
i) Reassembling the FRF.16 fragments received on the member links
into Frame Relay PDUs on the local PE end.
ii) Encapsulating the Frame Relay specific control information
from the multilink fragments into the PW packet.
iii) Transmitting the PW packets across the MPLS network to the
peer PE.
iv) Extracting the Frame Relay specific control information from
the PW packet on the remote PE end.
v) Fragmenting the Frame Relay PDUs into FRF.16 fragments on the
remote PE end.
vi) Forwarding the Frame Relay packets to the CE device associated
with the PW on the remote PE end.
The figure below (Figure 1) describes the reference model to support
Frame Relay PW with FRF.16 services.
|<--- Pseudowire (PW) -->|
| |
FRF.16 | |<-- PSN Tunnel -->| | FRF.16 or Frame Relay
Service V V V V Service
| +----+ +----+ |
+----+ | | PE1|==================| PE2| | +----+
| |----------|............PW1.............|----------| |
| CE1| | | | | | | |CE2 |
| |----------|............PW2.............|----------| |
+----+ | | |==================| | | +----+
^ | +----+ +----+ | ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 (CE1) Edge 2 (CE2)
Figure 1: Frame Relay PW with FRF.16 Service Reference Model
2. Specification of Requirements
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 RFC 2119.
3. Applicability Statement
Frame Relay PW with FRF.16 service is not intended to emulate the
traditional Frame Relay service perfectly. However, it can be used
for the applications that need Frame Relay transport service.
The following are the notable differences between the traditional
Frame Relay service and the protocol described in this document.
- The PE device connected to one of the two CE endpoints MUST support
FRF.16 services. The other PE device MUST support FRF.16 or
non-multilink Frame Relay services. All the implementations MUST
support this.
- The frame ordering can be preserved using the OPTIONAL sequence
number field in the control word. However, the implementations
are not required to support this feature.
- The Quality Of Service (QOS) model for traditional Frame Relay
can be emulated. But, this is outside the scope of this document.
- The Frame Relay FECN, BECN, DE and C/R bits transparent to the
MPLS network and they won't reflect the status of the MPLS network.
- Support for the Frame Relay Switched Virtual Circuit (SVC) and
Switched Permanent Virtual Circuit (SPVC) is outside the scope of
this document.
- The Frame Relay Local Management Interface (LMI) protocol will be
terminated locally on the PE devices connected to the Frame Relay
attachment circuits.
- The Frame Relay Link Integrity Protocol (LIP) protocol will be
terminated on each of the FRF.16 member links.
4. MPLS Pseudowire Type
There are two modes defined by [RFC4446] to map the Frame Relay
specific bits in the pseudowire control word. The legacy mapping
mode is identified by the pseudowire type 0x0001 and is referred
as Frame Relay DLCI (Martini Mode). The new mapping mode is
identified by the pseudowire type 0x0019 and is referred as
Frame Relay DLCI.
An implementation MUST support both these mapping modes while
signaling the pseudowire type to the remote PE.
5. General Encapsulation Method
In general, the encapsulation method followed for carrying the
Frame Relay PDUs over the MPLS network will be exactly same as
the one described in [RFC4619].
Each Frame Relay VC will be mapped to a separate pseudowire and
the implementations MUST support the "one-to-one" mapping mode
described in [RFC4619]. However, the implementations MUST NOT
support "port mode" mapping mode described in [RFC4619].
6. Encapsulation of Frame Relay Frames
6.1. Encapsulation of Frame Relay Frames for Frame Relay Service
The encapsulation method used by a PE device running the Frame Relay
service is identical to the one described in [RFC4619].
6.2. Encapsulation of Frame Relay Frames for FRF.16 Service
The encapsulation method used by a PE device running the FRF.16
service is similar to the one described in [RFC4619]. The following
are the prominent differences for this protocol.
- The PE device running the FRF.16 service will be reassembling the
FRF.16 fragments into complete Frame Relay PDUs.
- The PE device will generate the Frame Relay protocol specific
fields in the control word as below.
i) The PE MUST perform the bitwise logical OR of the
Command/Response (C/R) bits in the fragments associated with
a Frame Relay PDU and copy the result as the C bit in the
control word.
ii) The PE MUST perform the bitwise logical OR of the Discard
Eligible (DE) bits in the fragments associated with a Frame
Relay PDU and copy the result as the D bit in the control
word. If the D bit is not already set, the PE MAY set this
bit based on the ingress frame policing.
iii) The PE MUST perform the bitwise logical OR of the Forward
Explicit Congestion Notification (FECN) bits in the fragments
associated with a Frame Relay PDU and copy the result as the
F bit in the control word. If the F bit is not already set,
the PE MAY set this bit to reflect the congestion detected
by the PE.
iv) The PE MUST perform the bitwise logical OR of the Backward
Explicit Congestion Notification (BECN) bits in the fragments
associated with a Frame Relay PDU and copy the result as the
B bit in the control word. If the B bit is not already set,
the PE MAY set this bit to reflect the congestion detected
by the PE.
7. Decapsulation of Frame Relay Frames
7.1. Decapsulation of Frame Relay Frames for Frame Relay Service
The decapsulation method used by a PE device running the Frame Relay
service is identical to the one described in [RFC4619].
7.2. Decapsulation of Frame Relay Frames for FRF.16 Service
The decapsulation method used by a PE device running the FRF.16
service is similar to the one described in [RFC4619]. The following
are the prominent differences for this protocol.
- The PE device will process the Frame Relay protocol specific
fields in the control word as below.
i) The PE MUST copy the C bit in the control word as the C/R bit
in the Frame Relay header of all the FRF.16 fragments
associated with this PDU.
ii) The PE MUST copy the D bit in the control word as the DE bit
in the Frame Relay header of all the FRF.16 fragments
associated with this PDU.
iii) The PE MUST copy the F bit in the control word as the FECN
bit in the Frame Relay header of all the FRF.16 fragments
associated with this PDU.
If the F bit is set to 0, the FECN bit may be set to 1,
depending on the congestion state of the PE device in the
forward direction. Changing the state of this bit by a PE
is OPTIONAL.
iv) The PE MUST copy the B bit in the control word as the BECN
bit in the Frame Relay header of all the FRF.16 fragments
associated with this PDU.
If the B bit is set to 0, the BECN bit may be set to 1,
depending on the congestion state of the PE device in the
backward direction. Changing the state of this bit by a PE
is OPTIONAL.
- The PE device running the FRF.16 service will be fragmenting the
Frame Relay PDUs into FRF.16 fragments.
8. Fault Management
A PE device MUST provide the following fault management handling
operations.
- If a PE detects a service affecting failure on the CE end for a
Frame Relay DLCI, it MUST communicate to the remote PE with the
Frame Relay PVC status.
- When a PE receives a Frame Relay PVC failure status message from
the remote PE, it SHOULD communicate to the CE with the Frame Relay
PVC status.
A PE SHOULD send a Frame Relay LMI PVC status message to the CE
to indicate the Frame Relay DLCI failure. A PE SHOULD select
the best matching FRF.16 member link to send the Frame Relay PVC
status message.
9. Security Considerations
PWE3 provides no means of protecting the contents or delivery of the
PW packets on behalf of the native service. PWE3 may, however,
leverage security mechanisms provided by the MPLS Tunnel Layer. A
more detailed discussion of PW security is given in [RFC3985,
RFC4447, RFC3916].
10. Normative References
[RFC4619] Martini, L., Kawa, C., and Malis, A., "Encapsulation
Methods for Transport of Frame Relay over Multiprotocol
Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[FRF16.1] FRF.16.1, Multilink Frame Relay UNI/NNI Implementation
Agreement, Frame Relay Forum, May 2002.
11. Informative References
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
Brayley, J., and Koleyni, G., "Encapsulation Methods for
Transport of Asynchronous Transfer Mode (ATM) over MPLS
Networks", RFC 4717, December 2006.
12. Contributors
Authors's Addresses
Eswaran Srinivasan
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089, USA
EMail: esriniva@juniper.net
Luis Tomotaki
Verizon
400 International Parkway
Richardson, TX 75081, USA
EMail: luis.tomotaki@verizon.com
Contributing Author Information
Richard Li
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: rli@juniper.net
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
