DOCSLIB.ORG

Gr Ngp 009 V1.1.1 (2019-02)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Gr Ngp 009 V1.1.1 (2019-02) ETSI GR NGP 009 V1.1.1 (2019-02) GROUP REPORT Next Generation Protocols (NGP); An example of a non-IP network protocol architecture based on RINA design principles Disclaimer The present document has been produced and approved by the Next Generation Protocols (NGP) ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. 2 ETSI GR NGP 009 V1.1.1 (2019-02) Reference DGR/NGP-009 Keywords API, architecture, internet, meta-protocol, network, next generation protocol, protocol ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format at www.etsi.org/deliver. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. © ETSI 2019. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETM are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. GSM® and the GSM logo are trademarks registered and owned by the GSM Association. ETSI 3 ETSI GR NGP 009 V1.1.1 (2019-02) Contents Intellectual Property Rights ................................................................................................................................ 5 Foreword ............................................................................................................................................................. 5 Modal verbs terminology .................................................................................................................................... 5 Introduction ........................................................................................................................................................ 5 1 Scope ........................................................................................................................................................ 7 2 References ................................................................................................................................................ 7 2.1 Normative references ......................................................................................................................................... 7 2.2 Informative references ........................................................................................................................................ 7 3 Definition of terms, symbols and abbreviations ..................................................................................... 11 3.1 Terms ................................................................................................................................................................ 11 3.2 Symbols ............................................................................................................................................................ 13 3.3 Abbreviations ................................................................................................................................................... 13 4 Overview and motivation ....................................................................................................................... 15 4.1 What does the present document mean by "network protocol architecture"? .................................................. 15 4.2 What is the current network protocol architecture? .......................................................................................... 16 4.3 Summary of current issues at the network protocol architecture level ............................................................. 16 4.3.1 Structure ...................................................................................................................................................... 16 4.3.2 Protocol design ........................................................................................................................................... 17 4.3.3 Naming, addressing and routing ................................................................................................................. 18 4.3.4 Mobility and multi-homing ......................................................................................................................... 18 4.3.5 Quality of Service, resource allocation, congestion control ........................................................................ 18 4.3.6 Security ....................................................................................................................................................... 19 4.3.7 Network Management ................................................................................................................................. 19 4.4 Goals for a generic network protocol architecture ........................................................................................... 20 5 Structure ................................................................................................................................................. 21 5.1 A network service definition ............................................................................................................................ 21 5.2 Networks and distributed computing ................................................................................................................ 22 5.3 A repeating structural pattern: recursive Distributed IPC Facilities (DIFs) ..................................................... 22 5.4 Examples of DIF configurations ...................................................................................................................... 24 5.4.0 Introduction................................................................................................................................................. 24 5.4.1 Virtual Private LAN Service (VPLS) ......................................................................................................... 25 5.4.2 LTE Evolved Packet System (EPS) User Plane .......................................................................................... 26 5.4.3 Multi-tenancy Data Centre .......................................................................................................................... 27 5.5 Summary of RINA structural properties .......................................................................................................... 27 6 Generic protocol frameworks ................................................................................................................. 28 6.1 Internal structure of an IPC Process ................................................................................................................. 28 6.2 Data transfer: functions, protocols and procedures .......................................................................................... 30 6.2.1 Introduction................................................................................................................................................. 30 6.2.2 DTP PDU abstract syntax ........................................................................................................................... 30 6.2.3 DTCP PDU Formats ................................................................................................................................... 30 6.2.4 Overview of data-transfer procedures ......................................................................................................... 31 6.3 Layer management: protocol, functions and procedures .................................................................................. 32 6.3.1 Introduction................................................................................................................................................. 32 6.3.2 Layer management functions: enrollment ................................................................................................... 32 6.3.3 Layer management
Load more

Recommended publications
  • TR-221: Technical Specifications for MPLS in Mobile Backhaul Networks
    TECHNICAL REPORT TR-221 Technical Specifications for MPLS in Mobile Backhaul Networks Issue: 1 Amendment 2 Issue Date: September 2017 © The Broadband Forum. All rights reserved. Technical Specifications for MPLS in Mobile Backhaul Networks TR-221 Issue 1 Amendment 2 Notice The Broadband Forum is a non-profit corporation organized to create guidelines for broadband network system development and deployment. This Technical Report has been approved by members of the Forum. This Technical Report is subject to change. This Technical Report is copyrighted by the Broadband Forum, and all rights are reserved. Portions of this Technical Report may be copyrighted by Broadband Forum members. Intellectual Property Recipients of this Technical Report are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of this Technical Report, or use of any software code normatively referenced in this Technical Report, and to provide supporting documentation. Terms of Use 1. License Broadband Forum hereby grants you the right, without charge, on a perpetual, non-exclusive and worldwide basis, to utilize the Technical Report for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, products complying with the Technical Report, in all cases subject to the conditions set forth in this notice and any relevant patent and other intellectual property rights of third parties (which may include members of Broadband Forum). This license grant does not include the right to sublicense, modify or create derivative works based upon the Technical Report except to the extent this Technical Report includes text implementable in computer code, in which case your right under this License to create and modify derivative works is limited to modifying and creating derivative works of such code.
    [Show full text]
  • Performance Evaluation of TCP Multihoming for IPV6 Anycast Networks and Proxy Placement
    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2015 Performance Evaluation of TCP Multihoming for IPV6 Anycast Networks and Proxy Placement Raya Alsharfa University of Central Florida Part of the Electrical and Electronics Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Masters Thesis (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Alsharfa, Raya, "Performance Evaluation of TCP Multihoming for IPV6 Anycast Networks and Proxy Placement" (2015). Electronic Theses and Dissertations, 2004-2019. 1350. https://stars.library.ucf.edu/etd/1350 PERFORMANCE EVALUATION OF TCP MULTIHOMING FOR IPV6 ANYCAST NETWORKS AND PROXY PLACEMENT by RAYA MAJID ALSHARFA B.S. NAJAF TECHNICAL COLLEGE, 2010 A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. in the Department of Electrical Engineering and Computer Science in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Fall Term 2015 Major Professor: Mostafa Bassiouni © 2015 Raya Majid Alsharfa ii ABSTRACT In this thesis, the impact of multihomed clients and multihomed proxy servers on the performance of modern networks is investigated. The network model used in our investigation integrates three main components: the new one-to-any Anycast communication paradigm that facilitates server replication, the next generation Internet Protocol Version 6 (IPv6) that offers larger address space for packet switched networks, and the emerging multihoming trend of connecting devices and smart phones to more than one Internet service provider thereby acquiring more than one IP address.
    [Show full text]
  • MPLS Layer-2 Vpns • MPLS Traffic Engineering • Summary
    Understanding MPLS BRKMPL - 1101 Khurram Waheed Systems Engineer #clmel Session Goals • Understand the problems MPLS is addressing • Understand major MPLS technology components • Understand typical MPLS applications • Understand benefits of deploying MPLS BRKMPL-1101 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public Agenda • Introduction • MPLS Basics • MPLS Layer-3 VPNs • MPLS Layer-2 VPNs • MPLS Traffic Engineering • Summary BRKMPL-1101 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public Introduction Why Multi-Protocol Label Switching? • SP/Carrier perspective – Reduce costs (CAPEX/OPEX); consolidate networks and maximise utilisation of resources. – Consolidated network for multiple Layer-2/3 services over same infrastructure – Support increasingly stringent SLAs (Voice + Video etc.) • Enterprise/end-user perspective – Campus/LAN – Need for network segmentation (users, applications, etc.) BRKMPL-1101 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public What is MPLS? Brief Summary • It’s all about labels … • Use the best of both worlds – Layer-2: efficient forwarding and traffic engineering – Layer-3: flexible and scalable • MPLS forwarding plane – Use of labels for forwarding Layer-2/3 data traffic – Labeled packets are switched; instead of routed • Leverage layer-2 forwarding efficiency • MPLS control/signalling plane – Use of existing IP control protocols extensions + new protocols to exchange label information • Leverage layer-3 control protocol flexibility and scalability BRKMPL-1101 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public MPLS Basics Topics Basics of MPLS Signalling and Forwarding • MPLS Reference Architecture Service (Clients) • MPLS Labels Layer-3 VPNs Layer-2 VPNs • MPLS Signalling and Forwarding Operations Transport IP/MPLS (LDP/RSVP-TE/BGP) MPLS Forwarding BRKMPL-1101 © 2015 Cisco and/or its affiliates.
    [Show full text]
  • A Holistic Survey of Network-Layer Multipath Junaid Qadir, Anwaar Ali, Kok-Lim Alvin Yau, Arjuna Sathiaseelan, Jon Crowcroft
    1 Exploiting the power of multiplicity: a holistic survey of network-layer multipath Junaid Qadir, Anwaar Ali, Kok-Lim Alvin Yau, Arjuna Sathiaseelan, Jon Crowcroft Abstract—The Internet is inherently a multipath network—for available on the Internet, traditional Internet technologies have an underlying network with only a single path connecting various focused mainly on single-path routing for the sake of its nodes would have been debilitatingly fragile. Unfortunately, simplicity and lower overhead. This has led to the artificial traditional Internet technologies have been designed around the restrictive assumption of a single working path between a source lockup of Internet’s capacity, lower fault tolerance and reli- and a destination. The lack of native multipath support constrains ability, and inflexible support for quality of service (QoS). network performance even as the underlying network is richly This is even in contrast to telephone networks, which have connected and has redundant multiple paths. Computer networks traditionally adopted multiple-path routing1 since it leads to can exploit the power of multiplicity—through which a diverse better reliability and greater customer satisfaction (due to the collection of paths is resource pooled as a single resource—to unlock the inherent redundancy of the Internet. This opens up lesser probability of call blocking) [2]. a new vista of opportunities promising increased throughput Notwithstanding the lack of native multipath support on (through concurrent usage of multiple paths) and increased the current Internet, there is a growing convergence in the reliability and fault-tolerance (through the use of multiple paths Internet community that multipath routing and forwarding, or in backup/ redundant arrangements).
    [Show full text]
  • Multihoming Support in Mobile IP Networks: Progress, Challenges and Solutions
    International Journal of Innovative Technology and Exploring Engineering (IJITEE) ISSN: 2278-3075, Volume-9 Issue-5, March 2020 Multihoming Support in Mobile IP Networks: Progress, Challenges and Solutions Mohammad Alreshoodi easily attained not only in urban areas but also in remote Abstract: IP network mobility has already emerged as a key environments. Many Internet access options can be exposed domain of wireless IP networking. The network research to mobile IP devices and networks while being on the move. community has taken great interest and paid considerable Wi-Fi hotspots are becoming available in many urban attention to advance IP mobility applications. Accordingly, locations and cellular access can be reached in rural areas. different advanced networking mechanisms have been considered to optimize IP network mobility. One of these mechanisms is The wide availability of these and other access technologies network multi-homing which has been the focus of many IP provides mobile IP networks with a number of wireless mobility studies within the academic research and IETF connectivity alternatives. Multi-interfaced mobile IP devices communities. The combination of network mobility and and multi-gateways mobile IP networks can use all these multi-homing has turned into a conceivable approach to opportunities to establish more resilience Internet access. effectively deal with expanding system availability and improving In addition, multihoming paves the way to have support of the performance of mobile IP network. There are many studies more effective networking techniques in mobile IP networks. proposed during the recent years to realize network multi-homing These include seamless handover among homogeneous and for the Network Mobility Basic Support (NEMO BS) protocol, a leading IETF IP mobility protocol.
    [Show full text]
  • Evaluating 5G Multihoming Services in the Mobilityfirst Future Internet Architecture
    Evaluating 5G Multihoming Services in the MobilityFirst Future Internet Architecture Parishad Karimi, Michael Sherman, Francesco Bronzino Ivan Seskar, Dipankar Raychaudhuri Inria, Paris WINLAB, [email protected] Rutgers University Abhimanyu Gosain fparishad,msherman,seskar,[email protected] Raytheon BBN Technologies [email protected] Abstract—In the recent years it has become increasingly etc can be deployed and evaluated. In this paper we focus evident that the current end-to-end host-centric communication on the implementation of mobility services, namely device paradigm will not be capable of meeting the ongoing demand multihoming and its deployment in testbeds including 5G for massive data rates and ultra-low latency. With the advent of fifth generation of cellular architecture (5G) to support these technologies. In Sec. III the principal design elements of requirements on the wireless edge of the network, the need the Mobilityfirst architecture are described along with how for core network solutions to play a complementary role is Mobilityfirst enables 5G services (specifically multihoming). conspicuous. In this paper we present and tackle some of the Next in Sec. IV the details for the components employed in the challenges of deploying a Future Internet Architecture (FIA), implementation are elaborated on. In Sec. V the experimental called MobilityFirst (MF), specifically for 5G use case scenarios. We report our findings of the deployment based on a setup methodology and results are presented. We discuss large scale on a small-scale testbed (ORBIT) and a nation-wide distributed implementation of the experimental setup in Sec. VI and testbed (GENI), and illustrate some results for the use case of finally Sec.
    [Show full text]
  • Mobility Vs Multihoming
    Mobility vs Multihoming Naveen Gundu Helsinki University of Technology Telecommunications Software and Multimedia Laboratory [email protected] Abstract example, In multihoming user subscribes different ISPs and networks for different services. User views different options In current scenario, use of mobile and Internet has been like cost effective, secure, quality service from one ISP and increasing and the increasing number of users are coming others. forward to use new services like mobility and multihom- The analysis of this paper presents the idea behind the mo- ing. Roaming users are interested to stay connected with bility and multihoming. The solutions provided with mobile network while moving from one network to another net- IP and layer 4 for both services and how these protocol so- work with multiple network interfaces e.g. WLAN and lutions are trying to fulfill the requirements. It also gives GPRS.Problems which might arise when mobile host moves difference between them. from one network to another network. Some mobility so- lutions have been introduced to ensure connections between networks,e.g., Mobile IPv4 & IPv6. 2 Background This paper gives a brief functional description of multi- homing and mobility, given requirements, problems associ- Here gives an overview about mobility and multihoming at ated with them, related solution to fulfill each requirements end host and site point of view. And also discusses problems and finally comparison between them. and requirements for further discussion. KEYWORDS: Mobility, Mobile IP, Multihoming, Routing, Site Multihoming, Host Multihoming, Node/end-host, ISP. 2.1 Multihoming Multihoming refers to a situation where an end-host having several parallel communication paths that it can use [4].
    [Show full text]
  • MPLS FAQ: Does "No Mpls Ip Propagate-Ttl" on the Ingress PE Router Also Apply to Ipv6 Packets in 6PE Or 6VPE Networks?
    MPLS FAQ: Does "no mpls ip propagate−ttl" on the ingress PE router also apply to IPv6 packets in 6PE or 6VPE networks? Document ID: 118697 Contributed by Luc De Ghein, Cisco TAC Engineer. Dec 23, 2014 Contents Introduction Does "no mpls ip propagate−ttl" on the ingress PE router also apply to IPv6 packets in 6PE or 6VPE networks? Introduction This document describes the impact of the command "mpls ip propagate−ttl" on IPv6 traffic. Does "no mpls ip propagate−ttl" on the ingress PE router also apply to IPv6 packets in 6PE or 6VPE networks? Answer: Yes, it does. This command hides the P routers from both an IPv4 and an IPv6 traceroute. Here is an IPv6 traceroute with "no mpls ip propagate−ttl" configured on the ingress Provider Edge (PE) router. CE1#trace Protocol [ip]: ipv6 Target IPv6 address: 2001:10:100:1::7 Source address: 2001:10:100:1::5 Insert source routing header? [no]: Numeric display? [no]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Priority [0]: Port Number [0]: Type escape sequence to abort. Tracing the route to 2001:10:100:1::7 1 2001:10:1:5::1 1 msec 1 msec 1 msec 2 2001:10:1:7::2 [AS 1] [MPLS: Label 23 Exp 0] 2 msec 1 msec 1 msec 3 2001:10:1:7::7 [AS 1] 2 msec 1 msec 2 msec The P routers are not present in the output of the traceroute. This proves that the propagation of Time To Live (TTL) from the IPv6 header to the Multiprotocol Label Switching (MPLS) header does not occur on the ingress PE router for IPv6 packets.
    [Show full text]
  • Copyrighted Material
    Index addresses Numbers & Symbols duplicate address detection, 89 ::/0 unicast address, 81 link-local, 285 ::1/28 unicast address, 81 addressing ::/128 unicast address, 81 classful addressing, 59 10 Gigabit Ethernet, 29 classless addressing, 59–60 10/100Base Ethernet, 29 Ethernet, 25–26 5620 SAM (Service Aware Manager), 7, 14 IPv6 7210 SAS (Service Access Switch), 12–13 anycast addresses, 80, 83–84 7450 ESS (Ethernet Service Switch), 11–12 multicast, 79, 82–83 7705 SAR (Service Aggregation unicast addresses, 79, 80–82 Router), 10–11 IPv4 address structure, 58–59 7750 SR (Service Router), 7, 9–10 IS-IS, 330–331 IP interface, configuration, 66–70 ND (Neighbor Discovery), 89 IS-IS behavior, 343 NSAP, 330 ports unicast addresses, 26, 58 access, 975 adjacencies network, 975 DR, 189–191 routing table, 121 IS-IS, establishing, 333–350 service components, 970 LDP peers, 535, 537 services configuration RSVP-TE Hello message, 623–629 components, 970–971 adjacency database, 124 customers, 971 administrative groups service identifiers, 971–972 CSPF algorithm and, 720–725 subscribers, 971 interfaces, 724 topologies recognized, 163 labs, 752–754 6over4 MPLS, 721 IPv6 packets and, 97–103 ring topology, 725–738 PE1 configuration, 99–100 Type 10 LSAs, 721–722 PE2 configuration, 102 administrative route tags, IS-IS, 421–428 6PE-IPv6 tunneling over MPLS, 648–656 advertising routers, 90 6VPE (IPv6 on VPN Router), 1191–1200 AFI (area format and identifier), 330 labs, 1208–1209 aggregate-prefix-match command, 587 AH (Authentication Header), 303 IPv6 header,
    [Show full text]
  • Release Notes for Cisco IOS Release 11.2(11) Software Feature Packs for Cisco 2500 Series Routers
    Doc. No. 78-4265-02 Release Notes for Cisco IOS Release 11.2(11) Software Feature Packs for Cisco 2500 Series Routers January 26, 1998 These release notes describe the Cisco Internetwork Operating System (Cisco IOS) Release 11.2(11)P feature packs for Cisco 2500 series routers. This document contains the following sections: • Platforms Supported on page 1 • What Is a Feature Pack? on page 2 • Using Cisco Feature Packs on page 2 • Loading Cisco IOS Release 11.2 Software on CiscoPro Routers on page 16 • Installation Tips on page 17 • Installing the Router Software Using a TFTP Server Application on page 18 • Related Documentation on page 22 • Cisco Connection Online on page 24 Platforms Supported The RSL supports the following Cisco 2500 series routers: • CiscoPro CPA2501, CPA2502, CPA2503, CPA2504, CPA2505, CPA2507, CPA2509, CPA2511, CPA2513, CPA2514, CPA2516, CPA2520, CPA2521, CPA2522, CPA2523, and CPA2524 • Cisco 2501, 2502, 2503, 2504, 2505, 2507, 2509, AS2509-RJ, 2510, 2511, AS2511-RJ, 2512, 2513, 2514, 2515, 2516, 2520, 2521, 2522, 2523, 2524, and 2525 Note The Cisco AS2509-RJ and AS2511-RJ only support software images for Cisco IOS Release 11.2(5)P or later. Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Copyright © 1998 Cisco Systems, Inc. All rights reserved. 1 What Is a Feature Pack? What Is a Feature Pack? The heart of a Cisco IOS software feature pack is a CD-ROM that contains a software image and the Router Software Loader (RSL), a Windows 95 application that loads the image onto the access router or server.
    [Show full text]
  • Deliverable D6.3 White Box Evaluation
    30-10-2019 Deliverable D6.3 White Box Evaluation Deliverable 6.3 Contractual Date: 31-10-2019 Actual Date: 30-10-2019 Grant Agreement No.: 856726 Work Package WP6 Task Item: Task 1 Nature of Deliverable: R (Report) Dissemination Level: PU (Public) Lead Partner: RENATER Document ID: GN4-3-19-23B128 Authors: Xavier Jeannin (RENATER), Mauro Campanella (GARR), Frederic Loui (RENATER), Edin Salguero (RENATER), Maxime Wisslé (RENATER), Christos Argyropoulos (GRNET), Jani Myyry (FUNET), Ivana Golub (PSNC), Tomasz Szewczyk (PSNC), Damian Parniewicz (PSNC) , Bojan Jakovljevic (AMRES), Pavel Benacek (CESnet), Marco Savi (GARR), Susanne Naegele Jackson (FAU/DFN), Tim Chown (Jisc) © GÉANT Association on behalf of the GN4-3 project. The research leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 856726 (GN4-3). Abstract This deliverable reviews whether new types of white box devices can be used by the research and education community and for which use cases. The ability to program the data plane thanks to a high abstract level language (P4) opens the door to new applications for research and education. Two use cases are presented here: In-band Network Telemetry and Distributed Denial of Service attack mitigation. The Router for Academia, Research and Education project (RARE) investigates also if it is possible to use open source Network Operating System (NOS). Table of Contents Executive Summary 1 1 Introduction 2 2 White Box 3 2.1 White Box for Research
    [Show full text]
  • Multiprotocol Label Switching Oneriot Yahoo Amazon Twitter Del.Icio.Us from Wikipedia, the Free Encyclopedia
    Multiprotocol Label Switching - Wikipedia, the free encyclopedia Page 1 of 8 Multiprotocol Label Switching OneRiot Yahoo Amazon Twitter del.icio.us From Wikipedia, the free encyclopedia Multiprotocol Label Switching (MPLS) is a Internet Protocol Suite mechanism in high-performance telecommunications networks which directs and carries data from one Application Layer network node to the next with the help of labels. MPLS makes it easy to create "virtual links" between BGP · DHCP · DNS · FTP · HTTP · IMAP · distant nodes. It can encapsulate packets of various IRC · LDAP · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · SIP · SMTP · SNMP · network protocols. SSH · Telnet · TLS/SSL · XMPP · MPLS is a highly scalable, protocol agnostic, data- (more) carrying mechanism. In an MPLS network, data packets are assigned labels. Packet-forwarding Transport Layer decisions are made solely on the contents of this label, without the need to examine the packet itself. TCP · UDP · DCCP · SCTP · RSVP · ECN · This allows one to create end-to-end circuits across any type of transport medium, using any protocol. (more) The primary benefit is to eliminate dependence on a Internet Layer particular Data Link Layer technology, such as ATM, frame relay, SONET or Ethernet, and eliminate the IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · need for multiple Layer 2 networks to satisfy IPsec · different types of traffic. MPLS belongs to the family of packet-switched networks. (more) MPLS operates at an OSI Model layer that is Link Layer generally considered to lie between traditional ARP/InARP · NDP · OSPF · definitions of Layer 2 (Data Link Layer) and Layer 3 Tunnels (L2TP) · PPP · Media Access (Network Layer), and thus is often referred to as a Control (Ethernet, DSL, ISDN, FDDI) · "Layer 2.5" protocol.
    [Show full text]