Generic Aggregation of Resource Reservation

Protocol (RSVP) for IPv4 and IPv6 Reservation over PCN

domains

Georgios Karagiannis, Anurag Bhargava

draft-ietf-tsvwg-rsvp-pcn-01

1

Outline

Main Changes Open issues Next steps

2

Main changes

Congestion-Level-Estimate field removed from Single Marking (SM) PCN and Controlled (CL) PCN objects (for both IPv4 and IPv6 object versions)

two new objects (IPv4 and IPv6) to be used with the PCN CL edge behavior (+ open issue)

two new CL based PCN objects defined used to carry number of flow identifiers for individual flows within an ingress-egress-aggregate that have recently experienced excess-marking

3

Main changes

C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // + + | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4

Open issues

two possible options of carrying PCN objects of C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs (see slide 6,7)

comments provided on the list: increase clarity of the draft (including examples)

Will be worked out Changes on relation between PCN ingress-egress-

aggregate and RSVP generic aggregated reservation states:

Each ingress – egress pair supports only one PCN IEA More than one RSVP generic aggregated reservation states can

be mapped to the PCN IEA (instead of mapping one RSVP generic aggregated reservation state to one PCN IEA)

Changes in terminology, Section 3.1 and 3.11 need to be worked out

reducing bandwidth without terminating flow (see slides 8, 9) 5

Open issues: possible options carrying new C-type CL PCN objects

Option 1: PCN objects of C-Types (RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) MUST be carried by the aggregated Resv message together with other PCN object C-Types

Advantage: No new message type needs to be used by signaling protocol

Disadvantage: objects can become larger than maximum transmission unit (MTU)

along a path to Aggregator Comment sent to tsvwg list on disadvantage:

number of flows is chosen such that objects do not become larger than (MTU) along a path to Aggregator

6

Open issues: possible options carrying new C-type CL PCN objects

Option 2: PCN objects of C-Types (RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) MUST be carried by NOTIFY messages (<flow descriptor list>) [RFC3473]

Advantage: total list of flow IDs that need to be sent to Aggregator can be

divided in smaller sets each of these sets can be then carried by one NOTIFY message,

without fragmentation Disadvantage:

signaling protocol needs to use an additional message type

7

Open issues: reducing bandwidth without terminating flow

PCN-ingress-node should be able to reduce bandwidth of an individual flow without terminating the flow Why?:

flows will not be terminated unnecessary and at the same time the IEA bandwidth is reduced to solve the severe congestion

How?: When for IEA supported by PCN-ingress-node incoming

traffic needs to be reduced then: based on a local policy and for same IEA, selects a number

of e2e RSVP sessions (individual flows) to be either terminated or reserved bandwidth of e2e RSVP sessions (individual flows) is reduced

8

Open issues: reducing bandwidth without terminating flow

Solution proposed on list: specify situation that in case of severe congestion flows

are terminated also emphasize that in some situations different policies

can be used to specify that instead of terminating complete bandwidth allocated to one or more flows, and by using mechanisms specified by RFC4680 and RFC 4495, only a percentage of bandwidth allocated to one or more flows is reduced

9

Next steps

Update draft based on received comments Assign one or more reviewers Other

10