The document summarizes the past, present, and future work of the IETF related to QoS signaling. It describes the early work on RSVP and IntServ in the late 1990s. It then outlines the various working groups formed to develop differentiated services, resource allocation protocols, policy frameworks, and sub-IP technologies. Finally, it discusses the Next Steps in Signaling working group, which aims to standardize a new IP signaling protocol to simplify and generalize RSVP signaling, along with its goals and deliverables.
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGSpijans
While smart factories are becoming widely recognized as a fundamental concept of Industry 4.0, their implementation has posed several challenges insofar that they generate and process vast amounts of security critical and privacy sensitive data, in addition to the fact that they deploy IoT heterogeneous and constrained devices communicating with each other and being accessed ubiquitously through lossy networks. In this scenario, the routing of data is a specific area of concern especially with the inherent constraints and limiting properties of such devices like processing resources, memory capacity and battery life. To suit these constraints and to provide the required connectivity, the IETF has developed several standards, among them the RPL routing protocol for Low powerand Lossy Networks (LLNs). However, and even though RPL provides support for integrity and confidentiality of messages, its security may be compromised by several threats and attacks. We propose in this work TRM-RPL, a Trust based Routing Metric for the RPL protocol in an IIoT based environments. TRM-RPL uses a trust management mechanism to detect malicious behaviors and resist routing attacks while providing QoS guarantees. In addition, our model addresses both node and link trust and follows a multidimensional approach to enable
an accurate trust assessment for IoT entities. TRM-RPL is implemented, successfully tested and compared with the standard RPL protocol where its effectiveniness and resilience to attacks has been proved to be better.
Rajesh Kumar Sundararajan, Assistant VP of Product Management at Aricent, gave a talk about TRILL and Datacenter technologies at the Interop Show in Las Vegas, May 2012.
Flexible Data Centre Fabric - FabricPath/TRILL, OTV, LISP and VXLANCisco Canada
This presentation will discuss the evolving Data Centre Fabric, FabricPath, VXLAN, LISP, LISP Host Mobility, OTV LAN Extension, Mobility with Extended Subnets and Nexus Fabric.
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGSpijans
While smart factories are becoming widely recognized as a fundamental concept of Industry 4.0, their implementation has posed several challenges insofar that they generate and process vast amounts of security critical and privacy sensitive data, in addition to the fact that they deploy IoT heterogeneous and constrained devices communicating with each other and being accessed ubiquitously through lossy networks. In this scenario, the routing of data is a specific area of concern especially with the inherent constraints and limiting properties of such devices like processing resources, memory capacity and battery life. To suit these constraints and to provide the required connectivity, the IETF has developed several standards, among them the RPL routing protocol for Low powerand Lossy Networks (LLNs). However, and even though RPL provides support for integrity and confidentiality of messages, its security may be compromised by several threats and attacks. We propose in this work TRM-RPL, a Trust based Routing Metric for the RPL protocol in an IIoT based environments. TRM-RPL uses a trust management mechanism to detect malicious behaviors and resist routing attacks while providing QoS guarantees. In addition, our model addresses both node and link trust and follows a multidimensional approach to enable
an accurate trust assessment for IoT entities. TRM-RPL is implemented, successfully tested and compared with the standard RPL protocol where its effectiveniness and resilience to attacks has been proved to be better.
Rajesh Kumar Sundararajan, Assistant VP of Product Management at Aricent, gave a talk about TRILL and Datacenter technologies at the Interop Show in Las Vegas, May 2012.
Flexible Data Centre Fabric - FabricPath/TRILL, OTV, LISP and VXLANCisco Canada
This presentation will discuss the evolving Data Centre Fabric, FabricPath, VXLAN, LISP, LISP Host Mobility, OTV LAN Extension, Mobility with Extended Subnets and Nexus Fabric.
Update on IRATI technical work after month 6Eleni Trouva
Summary of the technical work done by the project during the first six months, in the following areas:
* Use cases description and requirements analysis
* RINA specifications
* Software design and implementation
* Experimental infrastructure setup
Congestion Control in Recursive Network ArchitecturesICT PRISTINE
Presentation on Congestion Control in Recursive Network
Architectures at IETF 95, in the IRTF research group, Internet Congestion Control (ICCRG) meeting.
Generalized Multi-Protocol Label Switching (GMPLS) is a protocol suite extending MPLS to manage
further classes of interfaces and switching technologies other than packet interfaces and switching, such
as time division multiplexing, layer-2 switching, wavelength switching and fiber-switching.
GMPLS (Generalized Multiprotocol Label Switching), also known as Multiprotocol Lambda Switching. In
particular, GMPLS will provide support for photonic networking, also known as optical communications.
Update on IRATI technical work after month 6Eleni Trouva
Summary of the technical work done by the project during the first six months, in the following areas:
* Use cases description and requirements analysis
* RINA specifications
* Software design and implementation
* Experimental infrastructure setup
Congestion Control in Recursive Network ArchitecturesICT PRISTINE
Presentation on Congestion Control in Recursive Network
Architectures at IETF 95, in the IRTF research group, Internet Congestion Control (ICCRG) meeting.
Generalized Multi-Protocol Label Switching (GMPLS) is a protocol suite extending MPLS to manage
further classes of interfaces and switching technologies other than packet interfaces and switching, such
as time division multiplexing, layer-2 switching, wavelength switching and fiber-switching.
GMPLS (Generalized Multiprotocol Label Switching), also known as Multiprotocol Lambda Switching. In
particular, GMPLS will provide support for photonic networking, also known as optical communications.
Our approach in this thesis is that, we have designed and built a National Carrier based core and edge network to simulate a real live scenario that spans the kingdom of Saudi Arabia. Some of the results in the thesis are presented against simulation time and some against network load.how to implement mpls on network
Performance of MPLS-based Virtual Private Networks and Classic Virtual Privat...TELKOMNIKA JOURNAL
Multiprotocol Label Switching (MPLS) is effective in managing and utilizing available network bandwidth. It has advanced security features and a lower time delay. The existing literature has covered the performance of MPLS-based networks in relation to conventional Internet Protocol (IP) networks. But, too few literatures exist on the performance of MPLS-based Virtual Private Networks (VPN) in relation to traditional VPN networks. In this paper, a comparison is made between the effectiveness of the MPLS-VPN network and a classic VPN network using simulation studies done on OPNET®. The performance metrics used to carry out the comparison include; End to End Delay, Voice Packet Sent/Received and Label Switched Path’s Traffic. The simulation study was carried out with Voice over Internet Protocol (VoIP) as the test bed. The result of the study showed that MPLS-based VPN networks outperform classic VPN networks.
IETF building block in the LwM2M Ecosystem (IoT World 2017 Workshop)Open Mobile Alliance
This presentation is delivered by Hannes Tschofening, ARM and Co-chair of IETF ACE & OAuth WGs.
IETF has developed a Constrained Application Protocol (CoAP) which is designed to easily translate to HTTP for simplified integration with the web. It is intended for use in resource constrained internet devices. OMA LwM2M uses CoAP as a transport mechanism. In this presentation, our speaker from IETF will provide you with an introduction to CoAP:
● What is CoAP
● How CoAP works
● What other IETF standards are used by LwM2M
● What is next for IETF in this space
PLNOG14: Evolved Programmable Network, architektura dla sieci operatorskich -...PROIDEA
Krzysztof Konkowski - Cisco Systems
Language: English
Service Provider networks evolve to benefit from virtualisation, programmability, automation and other cutting edge technologies, enabling SPs to streamline their services and keep profitable on competitive market. Being able to adopt new technologies is bound to alleging network architecture, adding new components on top of Access, Aggregation, Core, and Service Edge. Cisco for past years has been developing CVD program - Cisco Validated Design. One of the work groups is dedicated to creating and maintaining EPN solution - Evolved Programmable Network - along with documentation based on cyclic test campaigns, Design & Implementation Guides, and other information. The session will cover EPN - its fundamental blocks, scenarios & equipment tested, where to search for information and how to use them.
Register for the next PLNOG edition: krakow.plnog.pl
On the migration of a large scale network from i pv4 to ipv6 environmentIJCNCJournal
This work mainly addresses the design a large scale network using dual stack mechanisms. We focused on
the most important theoretical concepts of the IPv6 protocol, such as addressing, address allocation,
routing with the OSPF and BGP protocols and routing protocols performance in dual stack network using
GNS3 and Wireshark simulators. we have a tendency to measure a perfect model and a true large-scale
network atmosphere victimization out there end-to-end activity techniques that focuses on a large-scale
IPv4 and IPv6 backbone and created performance the IPv4 and IPv6 network. In this paper, we compiled
IPv6 address planning in large scale network, performance statistics of each network in terms of TCP
throughput, delay jitters, packet loss rate, and round trip time. It is found that, a minor degradation within
the throughput of the TCP, delay jitter, a lower packet loss rate, and a rather longer round trip time are
occurred in a real large scale dual stack network
Advances in IPv6 in Mobile Networks Globecom 2011John Loughney
IPv6 is ready, IPv6 is being deployed. This presentation gives an update on how to use IPv6 in mobile and cellular networks. This provides an update on IPv6 usage in mobile networks. It gives recommendations on what areas are under development and references documents for more details.
"Converged Communications -- Impact and Requirements on future handsetsJohn Loughney
"Converged Communications -- Impact and Requirements on future handsets" at IWPC Session: Future Handset Applications vs. Next-Gen Hardware December 4th - 7th 2007.
http://www.iwpc.org/Workshop_Folders/07_12_Handset_Apps/Handset_Nokia.htm
Quality of Service at the Internet Engineering Task ForceJohn Loughney
"Quality of Service at the Internet Engineering Task Force" Workshop on "End-to-End Quality of Service. What is it? How do we get it?" Geneva, 1-3 October 2003.
Update on current state of 3G and IPv6 deployment .
"The State of 3G/GPRS IPv6 Deployment", North American IPv6 Technology Conference, September 20th, 2005.
IP QoS signaling in the IETF:Past, Present and Future
1. IP QoS signaling in the IETF:
Past, Present and Future
John A. Loughney
john.loughney@nokia.com
NSIS WG Chair
http://www.ietf.org/html.charters/nsis-charter.html
2. Background Material
“Watching the Waist of the
Protocol Hourglass” email WWW phone...
Steve Deering - SMTP HTTP RTP...
IETF 51 Plenary, London TCP UDP…
http://www.iab.org/Documents/hourglass-london-
ietf.pdf IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Workshop on end-to-end QoS.
What is it? How do We Get It?
3. Ancient History
First there was ST-II, which begat RSVP.
IntServ was developed concurrently.
RSVP started simple, but eventually ended up as
a fairly complicated protocol, partly related to
multicast support and IntServ support.
In reaction to scalability concerns, DiffServ work
was started.
Workshop on end-to-end QoS.
What is it? How do We Get It?
4. Major Work Related to QoS in
the IETF
Integrated Services (intserv)
Resource Reservation Setup Protocol (rsvp)
Integrated Services over Specific Link Layers (issll)
Differentiated Services (diffserv)
Resource Allocation Protocol (rap)
Policy Framework (policy)
Sub-IP (ccamp, gsmp, mpls, tewg)
Next Steps in Signaling (nsis)
Workshop on end-to-end QoS.
What is it? How do We Get It?
5. Integrated Services (intserv)
Concluded December 2000
The working group will focus on defining a minimal set of
global requirements which transition the Internet into a
robust integrated-service communications infrastructure.
The Use of RSVP with IETF Integrated Services - RFC2210
Specification of the Controlled-Load Network Element Service -
RFC2211
Specification of Guaranteed Quality of Service - RFC2212
Workshop on end-to-end QoS.
What is it? How do We Get It?
6. Resource Reservation Setup
Protocol (rsvp)
Concluded May 2001
The primary purpose of this working group is to evolve the
RSVP specification and to introduce it into the Internet
standards track. The task of the RSVP Working Group,
creating a robust specification for real-world
implementations of RSVP and parallel IETF working group
that is considering the service model for integrated service.
RSVP Version 1 Applicability - RFC 2208
RSVP Version 1 Message Processing Rules - RFC 2209
RSVP Operation Over IP Tunnels - RFC 2746
RSVP Cryptographic Authentication - RFC 2747
RSVP Refresh Overhead Reduction Extensions - RFC 2961
RSVP Cryptographic Authentication-New Message Type - RFC 3097
Workshop on end-to-end QoS.
What is it? How do We Get It?
7. Integrated Services over
Specific Link Layers (issll)
Concluded May 2002
The ISSLL Working Group defines specifications and
techniques needed to implement Internet Integrated
Services capabilities within specific network technologies.
Format of the RSVP DCLASS Object - RFC 2996
Specification of the Null Service Type - RFC 2997
A Framework For IntServ Operation Over Diffserv Networks - RFC
2998
RSVP Reservations Aggregation - RFC 3175
Workshop on end-to-end QoS.
What is it? How do We Get It?
8. Differentiated Services
(diffserv)
Concluded Feb 2003
The differentiated services approach to providing quality of
service in networks employs a small, well-defined set of
building blocks from which a variety of aggregate behaviors
may be built.
Definition of the DiffSerField in the IPv4 and IPv6 Headers - RFC 2474
An Architecture for Differentiated Services - RFC 2475
An Expedited Forwarding PHB - RFC 3246
Assured Forwarding PHB Group - RFC 2597
Def. of DiffServ Per Domain Behaviors & Rules for their Specification -
RFC 3086
Workshop on end-to-end QoS.
What is it? How do We Get It?
9. Resource Allocation Protocol
(rap)
Dormant
The working group will define general-purpose objects that
facilitate the manipulation of policies and provisioned
objects available through COPS and COPS-PR. Where
appropriate, these will include frameworks clarifying the
applicability of COPS objects and the best practices for the
definition of additional objects defined in other working
groups.
The COPS (Common Open Policy Service) Protocol - RFC 2748
COPS usage for RSVP - RFC 2749
A Framework for Policy-based Admission Control - RFC 2753
COPS Usage for Policy Provisioning - RFC 3084
Workshop on end-to-end QoS.
What is it? How do We Get It?
10. Policy Framework (policy)
Dormant
This working group has three main goals. First, to provide a
framework that will meet these needs. Second, to define an
extensible information model and specific schemata
compliant with that framework that can be used for general
policy representation. Third, to extend the core information
model and schema to address the needs of QoS traffic
management.
Policy Core Information Model - Version 1 Specification - RFC 3060
Terminology for Policy-Based Management - RFC 3198
Policy Core Information Model Extensions - RFC 3460
Workshop on end-to-end QoS.
What is it? How do We Get It?
11. Common Control and
Measurement Plane (ccamp)
Active
Coordinates the work within the IETF defining a common
control plane and a separate common measurement plane
for ISP and SP core tunneling technologies.
GMPLS Signaling Functional Description - RFC 3471
GMPLS Signaling CR-LDP Extensions - RFC 3472
GMPLS Signaling RSVP-TE Extensions - RFC 3473
Workshop on end-to-end QoS.
What is it? How do We Get It?
12. General Switch Management
Protocol (gsmp)
Active
Provides switch configuration control and reporting, port
management, connection control, QoS and traffic
engineering control and the reporting of statistics and
asynchronous events for MPLS label switch devices, all
either from or to a third party controller.
GSMP V3 - RFC 3292
GSMP Packet Encapsulations for ATM, Ethernet and TCP - RFC 3293
GSMP Applicability - RFC 3294
Workshop on end-to-end QoS.
What is it? How do We Get It?
13. Multiprotocol Label Switching
(mpls)
Active
Responsible for standardizing a base technology for using
label switching and for the implementation of label-switched
paths over various link-level technologies.
Requirements for Traffic Engineering Over MPLS - RFC 2702
Multiprotocol Label Switching Architecture - RFC 3031
RSVP-TE: Extensions to RSVP for LSP Tunnels - RFC 3209
MPLS Support of Differentiated Services - RFC 3270
Workshop on end-to-end QoS.
What is it? How do We Get It?
14. Internet Traffic Engineering
(tewg)
Active
Defined as that aspect of Internet network engineering
concerned with the performance optimization of traffic
handling in operational networks, with the main focus of the
optimization being minimizing over-utilization of capacity
when other capacity is available in the network.
Overview and Principles of Internet Traffic Engineering - RFC 3272
Applicability Statement for Traffic Engineering with MPLS - RFC 3346
Network Hierarchy and Multilayer Survivability - RFC 3386
Requirements for Support of DiffServ-aware MPLS Traffic Engineering
- RFC 3564
Workshop on end-to-end QoS.
What is it? How do We Get It?
15. NSIS Charter (1/2)
The Next Steps in Signaling Working Group is responsible for
standardizing an IP signaling protocol with QoS signaling as
the first use case. This working group will concentrate on a
two-layer signaling paradigm. The intention is to re-use,
where appropriate, the protocol mechanisms of RSVP, while
at the same time simplifying it and applying a more general
signaling model.
The existing work on the requirements, the framework and
analysis of existing protocols will be completed and used as
input for the protocol work.
Workshop on end-to-end QoS.
What is it? How do We Get It?
16. NSIS Charter (2/2)
NSIS will develop a transport layer signaling protocol for the
transport of upper layer signaling. In order to support a
toolbox or building block approach, the two-layer model will
be used to separate the transport of the signaling from the
application signaling. This allows for a more general signaling
protocol to be developed to support signaling for different
services or resources, such as NAT & firewall traversal and
QoS resources. The initial NSIS application will be an
optimized RSVP QoS signaling protocol. The second
application will be a middle box traversal protocol. It may be
that a rechartering of the working group occurs before the
completion of this milestone.
Workshop on end-to-end QoS.
What is it? How do We Get It?
17. What NSIS Will Do
Requirements of a QoS Solution for Mobile IP - RFC 3583
Submitted 'Signaling Requirements' to IESG for publication as an
Informational RFC.
Submit 'RSVP Security Properties' to IESG as Informational RFC
Submit 'NSIS Threats' to IESG as Informational RFC
Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational
RFC
Submit 'Next Steps in Signaling: Framework' to IESG for publication as
Informational RFC
Submit 'NSIS Transport Protocol' to IESG for publication for Proposed
Standard
Submit 'NSIS QoS Application Protocol' to IESG for publication for
Proposed Standard
Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for
publication for Proposed Standard end-to-end QoS.
Workshop on
What is it? How do We Get It?
18. NSIS Overview
“Requirements of a QoS Solution for MIP” &
”Requirements for Signaling Protocols” documents set
the goals for the work.
“Next Steps in Signaling: Framework” sets the stage for
the protocol work.
The NTLP; QoS NSLP & NAT/FW Traversal NSLP
protocols are the main deliverables.
Focusing initially on on-path signaling as this is seen as
a more critical problem for the Internet.
Off-path signaling may worked on, in a later phase, but
there scalability and end-to-end concerns.
Workshop on end-to-end QoS.
What is it? How do We Get It?
19. NSIS Summary
The work done in NSIS is meant to be general,
not focused on a single application and meant to
support other IETF protocols.
The current goal of the WG is to achieve a
scalable solution for signaling, but it is not meant
as a complete solution.
There is more work to be done.
Workshop on end-to-end QoS.
What is it? How do We Get It?
20. Summary
The IETF’s is concerned with working on solvable
problems.
QoS is more than just QoS classes, parameters,
applications, etc.
Internet-wide deployment issues are a concern.
Good possibilities for collaboration between the
IETF and other bodies, such as the ITU exist.
Participation is welcome.
Workshop on end-to-end QoS.
What is it? How do We Get It?
21. Questions?
Workshop on end-to-end QoS.
What is it? How do We Get It?