ITU-T X 84-2004 Support of frame relay services over MPLS core networks SERIES X DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Public data networks C Transmission signalling and swi.pdf

《ITU-T X 84-2004 Support of frame relay services over MPLS core networks SERIES X DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Public data networks C Transmission signalling and swi.pdf》由会员分享，可在线阅读，更多相关《ITU-T X 84-2004 Support of frame relay services over MPLS core networks SERIES X DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Public data networks C Transmission signalling and swi.pdf（28页珍藏版）》请在麦多课文档分享上搜索。

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T X.84TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2004) SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Public data networks Transmission, signalling and switching Support of frame relay services over MPLS core networks ITU-T Recommendation X

2、.84 ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS PUBLIC DATA NETWORKS Services and facilities X.1X.19 Interfaces X.20X.49 Transmission, signalling and switching X.50X.89 Network aspects X.90X.149 Maintenance X.150X.179 Administrative arrangements X.180X.199 OPEN SYSTEM

3、S INTERCONNECTION Model and notation X.200X.209 Service definitions X.210X.219 Connection-mode protocol specifications X.220X.229 Connectionless-mode protocol specifications X.230X.239 PICS proformas X.240X.259 Protocol Identification X.260X.269 Security Protocols X.270X.279 Layer Managed Objects X.

4、280X.289 Conformance testing X.290X.299 INTERWORKING BETWEEN NETWORKS General X.300X.349 Satellite data transmission systems X.350X.369 IP-based networks X.370X.399 MESSAGE HANDLING SYSTEMS X.400X.499 DIRECTORY X.500X.599 OSI NETWORKING AND SYSTEM ASPECTS Networking X.600X.629 Efficiency X.630X.639

5、Quality of service X.640X.649 Naming, Addressing and Registration X.650X.679 Abstract Syntax Notation One (ASN.1) X.680X.699 OSI MANAGEMENT Systems Management framework and architecture X.700X.709 Management Communication Service and Protocol X.710X.719 Structure of Management Information X.720X.729

6、 Management functions and ODMA functions X.730X.799 SECURITY X.800X.849 OSI APPLICATIONS Commitment, Concurrency and Recovery X.850X.859 Transaction processing X.860X.879 Remote operations X.880X.899 OPEN DISTRIBUTED PROCESSING X.900X.999 For further details, please refer to the list of ITU-T Recomm

7、endations. ITU-T Rec. X.84 (03/2004) i ITU-T Recommendation X.84 Support of frame relay services over MPLS core networks Summary MPLS has the potential to consolidate core networks and services, for example frame relay services, over a single common core infrastructure. This Recommendation defines f

8、rame relay over MPLS core network architecture, the transfer of frame relay control and user data information over the core MPLS network and the user plane protocol stack used at the edges of the MPLS core network. Two mapping modes for frame relay over MPLS are defined: the “one-to-one“ mapping mod

9、e and the “many-to-one“ mapping mode. The signalling and management planes are outside of the scope of this Recommendation. Source ITU-T Recommendation X.84 was approved on 19 March 2004 by ITU-T Study Group 17 (2001-2004) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. X.84 (03/2004) FO

10、REWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and is

11、suing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these t

12、opics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expressi

13、on “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability)

14、 and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recomm

15、endation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of

16、claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Re

17、commendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2004 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written pe

18、rmission of ITU. ITU-T Rec. X.84 (03/2004) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 1 4 Abbreviations and acronyms 2 5 Conventions 3 6 Architecture 3 6.1 General . 3 6.2 MPLS tunnel and VC LSPs 4 6.3 Relationship between frame relay VC and MPLS VC LSP . 5 6.4 Frame relay over MPLS m

19、apping modes. 6 7 Frame relay over MPLS requirements 6 8 Protocol stack and frame format. 7 8.1 Data transfer protocol stack 7 8.2 FR-MPLS packet format for the one-to-one mapping mode 7 9 FR-MPLS packet processing for one-to-one mapping mode . 10 9.1 Generating FR-MPLS packets 10 9.2 Reception of F

20、R-MPLS packets. 11 9.3 Handling of error conditions 13 9.4 Optional fragmentation and reassembly procedures 13 10 FR PVC provisioning . 15 11 Traffic management aspects . 15 12 Frame relay many-to-one mapping mode. 16 12.1 General . 16 12.2 Packet format for many-to-one mapping mode 16 12.3 Many-to-

21、one mode processing . 18 Appendix I Example of fragmentation for the one-to-one mapping mode. 19 BIBLIOGRAPHY 20 ITU-T Rec. X.84 (03/2004) 1 ITU-T Recommendation X.84 Support of frame relay services over MPLS core networks 1 Scope MPLS has the potential to consolidate core networks and services, for

22、 example frame relay services, over a single common core infrastructure. This Recommendation defines the architecture for frame relay over MPLS core network, the transfer of frame relay control and user-data information and the user plane protocol stack used at the edges of the MPLS core network. Th

23、is Recommendation defines two mapping modes for the provision of Frame Relay service over MPLS. One-to-one mode characterized by a one-to-one relation between a frame relay VC and a pair of unidirectional MPLS LSPs. The other mode is known as many-to-one mode. In this mode all FR VCs between a pair

24、of frame relay devices (CEs) controlled by a single frame relay signalling channel may be transparently transported in one pair of MPLS LSPs. NOTE This Recommendation does not cover Switch Virtual Connection and Soft PVC signalling between PEs. The control protocol for PVC status monitoring is for f

25、urther study. The signalling and management planes are outside of the scope of this Recommendation. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication

26、, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the curr

27、ently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Recommendation X.36 (2003), Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating

28、 Equipment (DCE) for public data networks providing frame relay data transmission service by dedicated circuit. ITU-T Recommendation X.76 (2003), Network-to-network interface between public networks providing PVC and/or SVC frame relay data transmission service. ITU-T Recommendation X.146 (2000), Pe

29、rformance objectives and quality of service classes applicable to frame relay. IETF RFC 3031 (2001), Multiprotocol Label Switching Architecture. IETF RFC 3032 (2001), MPLS Label Stack Encoding. IETF RFC 3270 (2002), Multi-Protocol Label Switching (MPLS) Support of Differentiated Services. 3 Definiti

30、ons This Recommendation defines the following terms: 3.1 customer edge (CE): The customer device connected to a provider edge device. Also known as frame relay DTE. 3.2 egress provider edge: The Provider Edge device that is the receiver of FR-MPLS packets. 3.3 FR-MPLS packet: Packets exchanged betwe

31、en an ingress provider edge and an egress provider edge. 2 ITU-T Rec. X.84 (03/2004) 3.4 ingress provider edge: The Provider Edge that transmits FR-MPLS packets. 3.5 provider edge (PE): A network edge device that provides a frame relay service over an MPLS network. 3.6 label switched path (LSP): The

32、 path through one or more MPLS nodes at one level of the hierarchy over which packets in a particular forwarding equivalence class are transmitted. 3.7 MPLS node: A device that is aware of MPLS control protocols, operates one or more layer three routing protocols and is capable of forwarding packets

33、 based on MPLS LSP labels. 3.8 penultimate hop popping: In MPLS architecture, penultimate hop popping is the mechanism by which the penultimate node (the node immediately before the egress node) pops the top label of the label stack prior to forwarding the packet to the egress node. Performing label

34、 popping by the penultimate node provides the egress node with the possibility to process optimally the packets. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations: Bc Committed Burst size Be Excess Burst size BECN Backward Explicit Congestion Notification C/R Command/

35、Response indicator CE Customer Edge CIR Committed Information Rate DCE Data Communication Equipment DE Discard Eligibility DLCI Data Link Connection Identifier DTE Data Terminal Equipment FCS Frame Check Sequence FECN Forward Explicit Congestion Notification FR Frame Relay FRS Frame Relay Service HD

36、LC High-level Data Link Control IETF Internet Engineering Task Force LSP Label Switched Path MPLS Multi-Protocol Label Switching MTU Maximum Transmission Unit NNI Network-to-Network Interface PDU Protocol Data Unit PE Provider Edge PHB Per Hop Behaviour PHP Penultimate Hop Popping ITU-T Rec. X.84 (0

37、3/2004) 3 PVC Permanent Virtual Connection QoS Quality of Service RFC Request For Comments SVC Switched Virtual Connection UNI User-to-Network Interface VC Virtual Circuit/Virtual Connection 5 Conventions PDU formats: In this Recommendation, PDU headers are structured as a group of four octets or wo

38、rds numbered from the left from 0 to 31. Bit order within single octet and multiple octets fields: In a single octet field, the left most bit of an octet is the high order or most significant bit. Similarly, in a multi-octet field, the left most bit of the whole field is the most significant bit. 6

39、Architecture 6.1 General The reference model for frame relay services over MPLS core networks is shown in Figure 1. It consists of the following elements: an MPLS core network; Provider Edge (PE) devices providing interworking functions between frame relay and MPLS. PEs can support frame relay UNIs

40、and/or NNIs; frame relay devices (DTEs/CEs) and FR networks (DCEs) connected to PEs with frame relay UNIs and/or NNIs. Figure 1/X.84 Frame relay over MPLS core network reference model Frame relay over MPLS core network architecture allows the interconnection of frame relay networks (DCEs) and/or fra

41、me relay devices (DTEs) over an MPLS network. In this architecture, frame relay networks and DTEs act as CE devices attached to PEs of the MPLS network as shown in Figure 1. The frame relay service is first provisioned between each frame relay DTE or DCE and 4 ITU-T Rec. X.84 (03/2004) the correspon

42、ding PE device. A Virtual Connection Label Switched Path (VC LSP) is then set up between the two PEs to complete the frame relay Virtual Connection (VC). The use of the MPLS network by two frame relay networks and/or devices is not visible to the end users. The end user protocol stacks remain intact

43、. The PE provides all mapping and encapsulation functions necessary to ensure that the service provided to the frame relay networks and/or devices is unchanged by the presence of an MPLS transport network. 6.2 MPLS tunnel and VC LSPs MPLS Label Switched Paths (LSPs) called “Tunnel LSPs“ connect a pa

44、ir of PEs. Several “Virtual Connection LSPs“ (VC LSPs) may be nested inside one Tunnel LSP (see Figure 2). Each VC LSP carries the traffic of a frame relay Permanent Virtual Connection (PVC) or Switched Virtual Connection (SVC) in one direction. Since LSPs are unidirectional, a pair of VC LSPs carry

45、ing traffic in opposite directions will usually be required for each frame relay PVC or SVC. Figure 2/X.84 Tunnel and VC LSPs In the case of tunnel LSPs, one of the tunnel LSP transports the FR-MPLS packets, for example, from PE X to PE Y and the other tunnel LSP transports FR-MPLS packets in the op

46、posite direction. The corresponding label does not tell PE Y about a frame relay virtual connection. If Penultimate Hop Popping (PHP) is used as per RFC 3031, PE Y will never see the tunnel label. If PE X itself is the penultimate hop, a tunnel label will not get pushed on. In this example, PE X is

47、the ingress PE device and PE Y the egress PE device. In the case when PE X has to send a frame relay frame to PE Y, it first pushes a VC label onto its label stack, and then pushes on a tunnel label. The VC label is not looked at until the FR-MPLS packet reaches PE Y. PE Y forwards the packet based

48、on the VC label. The “VC label“ identifies the frame relay virtual connection. In general, the VC label must always be at the bottom of the label stack, and the tunnel label, if present, must be immediately above the VC label. As the packet is transported across the MPLS network, additional labels m

49、ay be pushed on (and then popped off) as needed. If PE X and PE Y are directly adjacent MPLS nodes, then it may not be necessary to use a tunnel label at all. ITU-T Rec. X.84 (03/2004) 5 6.3 Relationship between frame relay VC and MPLS VC LSP Frame relay VCs are considered to be bidirectional objects mainly because of the way they are created and identified. A single frame relay Data Link Connection Identifier (DLCI) refers to the two directions of a frame relay VC. Frame relay signalling establishes the two directions simultaneo