1

Policy Routing Related IETF WGs

George Lee

2

Policy Routing Related IETF WGs

Policy Framework (policy) Resource Allocation Protocol (rap) Routing Policy System (rps) Differentiated Services (diffserv) Multiprotocol Label Switching (mpls) Inter-Domain Routing (idr) Inter-Domain Multicast Routing (idmr)

3

Policy Framework (policy) The need:

– to represent, manage, share, and reuse policies and policy information in a vendor-independent, interoperable, and scalable manner.

Three main goals– To provide a framework that will meet these needs.– To define an extensible information model and specific sch

emata compliant with that framework that can be used for general policy representation (called the core information model and schema). For now, only a directory schema will be defined.

– To extend the core information model and schema to address the needs of QoS traffic management (called the QoS information model and schemata).

4

policy

Internet-Drafts:– Policy Framework LDAP Core Schema (117786 bytes)

– Terminology for describing network policy and services (71750 bytes)

– Terminology for describing network policy and services (78660 bytes)

– QoS Policy Framework Information Model and Schema (97893 bytes)

– Policy Framework Core Information Model (170993 bytes)

– Requirements for a Policy Management System (202862 bytes)

– Policy Framework (79242 bytes)

5

Request For Comments – None

policy

6

Resource Allocation Protocol (rap) Internet-Drafts:

– A Framework for Policy-based Admission Control (49448 bytes)

– The COPS (Common Open Policy Service) Protocol (88343 bytes)

– RSVP Extensions for Policy Control (24415 bytes)– COPS usage for RSVP (32143 bytes)– Signaled Preemption Priority Policy Element (23758 bytes)– Identity Representation for RSVP (35285 bytes)– Definitions of Managed Objects for Common Open Policy

Service (COPS) Protocol Clients (51782 bytes)– COPS Usage for Policy Provisioning (67642 bytes)– Application and Sub Application Identity Policy Element

for Use with RSVP (7670 bytes)

7

Request For Comments – None

rap

8

Routing Policy System (rps) To provide standardization of protocols and

recommended practices necessary to support interoperability of the Internet Routing Registry (IRR). The IRR has been in use since 1995 based initially on the RIPE-181 policy language.

The activities of the RPS Working Group shall include– (1) defining a language, referred to as Routing Policy

Specification Language(RPSL),for describing routing policy constraints,

– (2) defining a simple and robust distributed registry model for publishing routing policy constraints, and

– (3) providing a forum for the discussion of tools for analyzing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems.

9

Internet-Drafts: – RIPE-181 to RPSL Transition Plan (15991 bytes)– Routing Policy System Security (98922 bytes)– PGP authentication for RIPE database updates (21049 bytes)– Distributed Routing Policy System (93948 bytes)– RPS IANA Issues (11506 bytes)

Request For Comments: – Routing Policy Specification Language (RPSL) (RFC 2622)

(140811 bytes)– Using RPSL in Practice (RFC 2650) (55272 bytes)

rps

10

Differentiated Services (diffserv) Need:

– for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic to support various types of applications

How:– A small bit-pattern (DS field) in each packet, in the IPv4

TOS octet or the IPv6 Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment (per-hop behavior, PHB) at each network node.

– A common understanding about the use and interpretation of the DS field is required for inter-domain use, multi-vendor interoperability, and consistent reasoning about expected service behaviors in a network.

11

Goal– To produce an informational framework document that descr

ibes more general aspects of the differentiated services environment.

– To allow experiments with other per-hop behaviors that can be used to produce additional services.

– To investigate the additional components necessary to support differentiated services, including such traffic conditioners as traffic shapers and packet markers that could be used at the boundaries of networks.

– To define a general conceptual model for boundary devices, including traffic conditioning parameters, and configuration and monitoring data.

– To define a MIB for diffserv nodes.– To analyze related security threats, especially theft of service

or denial of service attacks, and suggest counter-measures.

diffserv

12

The group will not work on:– mechanisms for the identification of individual traffic flows

– new signaling mechanisms to support the marking of packets

– end to end service definitions

– service level agreements

diffserv

13

Internet-Drafts: – A Framework for Differentiated Services (110733 bytes)– Format for Diffserv Working Group Traffic Conditioner Drafts

(6226 bytes)– A Conceptual Model for Diffserv Routers (78386 bytes)– Management Information Base for the Differentiated Services A

rchitecture (71760 bytes)– Per Hop Behavior Identification Codes (11448 bytes)– New Terminology for Diffserv (12745 bytes)

Request For Comments: – Definition of the Differentiated Services Field (DS Field) in the

IPv4 and IPv6 Headers (RFC 2474) (50576 bytes)– An Architecture for Differentiated Services (RFC 2475) (94788

bytes)– An Expedited Forwarding PHB (RFC 2598) (23656 bytes)– Assured Forwarding PHB Group (RFC 2597) (24068 bytes)

diffserv

14

Multiprotocol Label Switching (mpls) Problem Statement:

– Scalability of network layer routing » Using labels as a means to aggregate forwarding information, while wor

king in the presence of routing hierarchies. – Greater flexibility in delivering routing services

» Using labels to identify particular traffic which are to receive special services, e.g. QoS.

» Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding.

– Increased performance » Using the label-swapping paradigm to optimize network performance.

– Simplify integration of routers with cell switching based technologies » a) making cell switches behave as peers to routers (thus reducing the nu

mber of routing peers that a router has to maintain), » b) by making information about physical topology available to Network

Layer routing procedures, and » c) by employing common addressing, routing, and management procedu

res.

15

Objectives: – Specify standard protocol(s) for maintenance and distribution of label binding informatio

n to support unicast destination-based routing with forwarding based on label-swapping. – Specify standard protocol(s) for maintenance and distribution of label binding informatio

n to support multicast routing with forwarding based on label-swapping. – Specify standard protocol(s) for maintenance and distribution of label binding informatio

n to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing) with forwarding based on label-swapping.

– Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths different from the one constructed by destination-based forwarding with forwarding based on label-swapping.

– Specify standard procedures of carrying label information over various link level technologies.

– Specify a standard way to use the ATM user plane » Allow operation/co-existence with standard (ATM Forum, ITU, etc.) ATM control p

lane and/or standard ATM hardware» Specify a 'label swapping' control plane» Take advantage of possible mods/improvements in ATM hardware, for example the

ability to merge VCs – Discuss support for QOS (e.g. RSVP). – Define standard protocol(s) to allow direct host (e.g. server) participation.

mpls

16

Internet-Drafts: – A Framework for MPLS (180569 bytes)– Multiprotocol Label Switching Architecture (145481 bytes)– MPLS Label Stack Encoding (46971 bytes)– The Assignment of the Information Field and Protocol Identifier in the Q.294

1 Generic Identifier and Q.2957 User-to-user– Signaling for the Internet Protocol (51556 bytes)– Use of Label Switching on Frame Relay Networks Specification (54211 byte

s)– VCID Notification over ATM link for LDP (37147 bytes)– Carrying Label Information in BGP-4 (7829 bytes)– LDP Specification (249804 bytes)– Definitions of Managed Objects for the Multiprotocol Label Switching, Labe

l Distribution Protocol (LDP) (113471 bytes)– MPLS using ATM VC Switching (42928 bytes)– LDP State Machine (103384 bytes)– Extensions to RSVP for LSP Tunnels (105164 bytes)– Constraint-Based LSP Setup using LDP (91408 bytes)

mpls

17

Internet-Drafts: (continued)– MPLS Traffic Engineering Management Information Base Using SMIv2 (56

599 bytes)– MPLS Capability set (15052 bytes)– MPLS Support of Differentiated Services (99777 bytes)– MPLS Loop Prevention Mechanism (93696 bytes)– Framework for IP Multicast in MPLS (62700 bytes)– MPLS Label Switch Router Management Information Base Using SMIv2 (8

6863 bytes)– A Proposal to Incorporate ECN in MPLS (21291 bytes)– ICMP Extensions for MultiProtocol Label Switching (12430 bytes)– LDP Applicability (11092 bytes)– Applicability Statement for CR-LDP (13316 bytes)– Applicability Statement for Extensions to RSVP for LSP-Tunnels (17395 byt

es) Request For Comments:

– Requirements for Traffic Engineering Over MPLS (RFC 2702) (68386 bytes)

mpls

18

Inter-Domain Routing (idr) Goal:

– To standardize and promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter-Domain Routing Protocol (IDRP) as scalable inter-autonomous system routing protocols capable of supporting policy based routing for TCP/IP internets.

» The objective is to promote the use of BGP-4 to support IP version 4 (IPv4).

» IDRP is seen as a protocol that will support IPv4 as well as the next generation of IP (IPv6).

» The working group will plan a smooth transition between BGP-4 and IDRP.

19

Internet-Drafts: – A Border Gateway Protocol 4 (BGP-4) (134464 bytes)– Definitions of Managed Objects for the Fourth Version of Border Gateway Protoco

l (BGP-4) (58209 bytes)– Capabilities Negotiation with BGP-4 (6481 bytes)– Multiprotocol Extensions for BGP-4 (19456 bytes)– BGP Route Reflection An alternative to full mesh IBGP (18490 bytes)

Request For Comments: – A Border Gateway Protocol 3 (BGP-3) (RFC 1267) (80724 bytes)– Definitions of Managed Objects for the Border Gateway Protocol (Version 3) (RFC

1269) (25717 bytes)– Experience with the BGP Protocol (RFC 1266) (21938 bytes)– BGP Protocol Analysis (RFC 1265) (20728 bytes)– Default Route Advertisement In BGP2 And BGP3 Versions Of The Border Gatewa

y Protocol (RFC 1397) (4124 bytes)– BGP OSPF Interaction (RFC 1403) (36174 bytes)– Definitions of Managed Objects for the Fourth Version of the Border Gateway Prot

ocol (BGP-4) using SMIv2 (RFC 1657)(45505 bytes)

– BGP4/IDRP for IP---OSPF Interaction (RFC 1745) (43675 bytes)– BGP-4 Protocol Analysis (RFC 1774) (23823 bytes)

idr

20

Request For Comments: (continued) – Experience with the BGP-4 protocol (RFC 1773) (19936 bytes)– A Border Gateway Protocol 4 (BGP-4) (RFC 1771) (131903 bytes)– A BGP/IDRP Route Server alternative to a full mesh routing (RFC 1863) (37426 b

ytes)– Guidelines for creation, selection, and registration of an Autonomous System (AS)

(RFC 1930) (22073 bytes)– Autonomous System Confederations for BGP (RFC 1965) (13575 bytes)– BGP Route Reflection An alternative to full mesh IBGP (RFC 1966) (14320 bytes)– An Application of the BGP Community Attribute in Multi-home Routing (RFC 19

98) (16953 bytes)– BGP Communities Attribute (RFC 1997) (8275 bytes)– Using a Dedicated AS for Sites Homed to a Single Provider (RFC 2270) (12063 by

tes)– Multiprotocol Extensions for BGP-4 (RFC 2283) (18946 bytes)– Protection of BGP Sessions via the TCP MD5 Signature Option (RFC 2385) (1231

5 bytes)– BGP Route Flap Damping (RFC 2439) (86376 bytes)– A Framework for Inter-Domain Route Aggregation (RFC 2519) (25394 bytes)– Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing (RFC 254

5) (10209 bytes)

idr

21

Inter-Domain Multicast Routing (idmr) The group is expected to live only long enough

to see the existing work items progress through the standards track, and is not expected to take on new work items.

The specific work items are: – DVMRP, DVMRP MIB, Domain Wide Reports, IG

MP MIB, IGMP Proxying, IGMPv2, IGMPv3, Multicast Interop, Multicast Router Discovery, Multicast Routing MIB, and Multicast Traceroute.

22

Internet-Drafts: – Protocol Independent Multicast MIB (50535 bytes)– Internet Group Management Protocol MIB (34234 bytes)– IP Multicast Routing MIB (52937 bytes)– Distance-Vector Multicast Routing Protocol MIB (44491 byte

s)– A ''traceroute'' facility for IP Multicast. (47679 bytes)– Distance Vector Multicast Routing Protocol (98708 bytes)– Domain Wide Multicast Group Membership Reports (34124 by

tes)– Internet Group Management Protocol, Version 3 (98963 bytes)– IGMP Multicast Router Discovery (27798 bytes)– BGP Attributes for Multicast Tree Construction (15877 bytes)

idmr

23

Request For Comments: – Scalable Multicast Key Distribution (RFC 1949) (41853

bytes)

– Core Based Trees (CBT) Multicast Routing Architecture (RFC 2201) (38040 bytes)

– Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- (RFC 2189) (52043 bytes)

– Internet Group Management Protocol, Version 2 (RFC 2236) (51048 bytes)

– Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (RFC 2362) (159833 bytes)

– Interoperability Rules for Multicast Routing Protocols (RFC 2715) (49638 bytes)

idmr