Slide title In CAPITALS 50 pt Slide subtitle 32 pt Flow Distribution Rule Language for Multi-Access Nodes draft-larsson-mext-flow-distribution-rules-01 Conny Larsson Michael Eriksson Koshiro Mitsuya Kazuyuki Tasaka Romain Kuntz

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt Evolution of the Draft  There have been two documents about flow distribution languages –draft-mitsuya-monami6-flow-distribution-policy-04.txt –draft-larsson-monami6-filter-rules-02.txt  We agreed to merge the two documents into –draft-larsson-mext-flow-distribution-rules-00.txt

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt Which problem do we solve?  The MEXT charter includes the following deliverable: –"- A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]."  The “Multiple Care-of Address Registration” draft (draft-ietf-monami6- multiplecoa-08.txt) defines how multiple care-of addresses can be registered to one Home Address.  The mapping of a data flow between a Home Address and a Care-of Address is missing. CoA 1 CoA n HoA  The “Flow Distribution Rule Language for Multi- Access Nodes” draft defines a rule language as a mean to define and perform per flow path selection for a multi-homed node. –The rule language is defined using ABNF (Augmented Backus-Naur Form) [RFC5234]

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt Generating Routing Rules & Bindings CoARouting Rules Policy Interface type Cost of usage Available bandwidth Delay Etc. Events New interface Apps. open sockets Etc. Connection Manager Access Network Characteristics Selector 1 CoA 1 PID 1 Queuing delay Loss rate Jitter Latency Available Bandwidth Selector n CoA m PID m 123 How this is done de- pends on the Mobility Management protocol Flow Characteristics Needed bandwidth Maximum delay Etc. QoS support Security support Power consumption Charging Policy Etc. 1.An “event” occurs in the multi- homed node. This event serves as input to the Connection Manager. 2.The Connection Manager evaluates the input taking user and operator policy preferences into consideration. 3.Depending on the input: –Routing Rules are generated –Decision on which interface to use for each Routing Rule, i.e., the actual Binding between the PID in the Routing Rule and the physical interface. Scope of our draft The Path Identifier (PID) identifies a path between a multi-homed node and its peers. The PID maps to an interface on the multi-homed node, how this is done depends on the mobility mechanism. The selector defines which packets match the routing rule.

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt How Routing Rules are Applied to MIPv6 Routing Rules tcp peer port 80 on 11 udp peer port 53 on 800 tcp peer port 22 on 800 any on 11 Events Bindings BID 11:CoA1 BID 800:CoA2  A MN registers multiple care-of addresses as defined in draft- ietf-monami6-multiplecoa-08.txt Policies Connection Manager  An updated set of routing rules are sent from the MN to the HA as defined in draft-ietf-mext-flow-binding  An event occurs that generates new routing rules and bindings: –The PID equals to the BID. CoA 1CoA 2 MN Home Agent

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt Summary of List Discussions  There was one suggestion that RSVP TSPEC could be used to define the traffic specification: –Uncertainty about RSVP deployment.  Proposal to see if RFC4080 (NSIS Framework) could be used for MIP flow distribution: –Selectors could be described with a Message Routing Information (MRI)  draft-ietf-nsis-ntlp-16, section A.3.1  But it is not as exhaustive as what we propose - A MRI cannot match as much field: traffic class, extension headers,... –Some extensions to allow/deny a flow:  draft-ietf-nsis-nslp-natfw-18  Cannot bind the MRI to an equivalent of the PID. - Not needed when you transport the rule in the BU (BID is included in the BU already), - But needed if we separate it from the BU/BA.  We propose more than a "selector + path" association: - Round-robin, n-casting, conditional rule sets, etc. - Crucial in a mobile environment