Preliminary Chair: Jamal Hadi Salim 1) Chair (10 minutes) *) Administrivia *) Blue Sheets *) Jabber & Minute scribes appointment *) Agenda bashing *) WG Status 2) Joel M. Halpern (15-20 minutes) ForCES Forwarding Element Model, Pre-requisite reading material: ftp://ftp.znyx.com/users/hadi/private/forces/draft-ietf-forces-model-09.txt * Working on making things clearer with Jamal which resulted in an updated model. * Major changes to the way we talk about things: - LFBs used to have "elements" and "attributes" which are used in XML - Replaced "elements" and "attributes" with "component". - Made sure that all remaining "elements" and "attribute" referred to XML. REQUEST: If there are some missed please say so *Jamal has re-written Section 3 extensively Will be posting another version with the re-writes; right now working on Events section. Text was very awkward due to many changes *IANA considerations Added FCFS space, "ext-" QUESTION: Do we need to register frame types, atttribute types? ANSWER: Not right now. ***** We are close to last call. It is very close to done. Jamal: we need a fresh pair of eyes to read it 3) Avri Doria (10-15 minutes) ForCES Protocol Specification, Pre-requisite reading material at: http://www.ietf.org/internet-drafts/draft-ietf-forces-protocol-12.txt There will be a -13 soon. UPDATE: -13 has been posted .. In -12: * Replaced "element" to "component" but not "attribute". Will be fixed in -13. * Philosophical approach: strongly arguing for minimal change. Current working draft available at http://psg.com/~abri/ietf/draft-ietf-forces-protocol-13-0.txt * Figure4 changed, statemachine. * Figure 43 statemachine goes from Pre-Assoication to Associated, without a failover policy, goes back to pre-association. Teardown goes to not-associated. Changes recognized when synchronizing model and protocol docs. Think it's really close to ready. 4) Kentaro Ogawa (15 minutes) SCTP based TML (Transport Mapping Layer) for ForCES protocol Pre-requisite reading material at: http://www.ietf.org/internet-drafts/draft-ietf-forces-sctptml-00.txt * History: original version submitted by Jamal, June 2006. Draft mentions rationale for SCTP based TML, accepted as WG item. Discussions have been deferred, due to instability of protocol, model, etc. Now these other items are almost done. Now released as WG draft. * SCTP vs. TCP, UDP, DCCP TCP: SCTP uses messages, instead of byte stream. UDP: SCTP doesn't provide multicast DCCP: SCTP can do everything DCCP does. * Additional services that none of the others provide Multi-homing, runtime IP binding (ADDIP), a range of reliability shades + congestion control... * Why SCTP? SCTP has all features to provide robust TML. Very mature. Provides High Availability with little effort. Joel: 2 diff notions. We have defined things that there should be multiple TMLs. For interoperability we're going to have to pick one of them as mandatory to implement. I thought we had decided one. Are you arguing that we should change from TCP mandatory to SCTP? That would be a big issue. Ken: yes, that is what we are proposing. Joel: don't like those debates. Not the case that one is better than another. Think SCTP is A good choice. * Meeting TML requirements one socket 2 streams. Reliability: yes Congestion control: yes Timeliness: Message can be discarded if not sent before timeout. Prioritization: Multiple streams can be prioritized PL Addressing to peers: SCTP can replicate a packet to several destinations Not as good as UDP multicast, but saves local system memory b/w. Encapsulation: None needed by this TML HA (High Availability?): Multi-homing provides path diversity. If one of the peer IPs becomes unreachable, the others can take over without TML intervention. Reachability fault detection. Can migrate IP addresses from one node to the other Discussion: Should SCTP be mandatory? Joel: A number of problems with making this mandatory to implement TML. Draft isn't really done. Can't tell reading that draft how to use SCTP. It's not done. In order for AD to approve protocol, it must be able to run. Changing horses right now would delay considerably getting this done. Like TML, would like to see it finished. Frankly, SCTP is not sufficiently ubiquitous. People know how to work with UDP and TCP a heck of a lot better. In routers, making TCP and UDP work well for control operations has been an interesting undertaking of many years. Sue: it's not always done Joel: Mandating that? Jamal: there are a few other WGs who have mandated SCTP over TCP. Can't use UDP because of lack of congestion control. TCP has issues/challenges: head of line blocking. Ubiquity issue: it has improved because of other WGs who are forcing SCTP as the way to go. Our implementation uses TCP at the moment. Joel: not saying you shouldn't be able to use SCTP, but for interoperability we should make sure it's something that vendors will get right. Document needs to be in good shape, it might take too long. Jamal: TML for TCP also needs work. Avri: q: implementations that we have now, are they all TCP at the moment? Would they still count if SCTP was mandatory? Are we back to no implementations? Ross: Whether they count is in the eye of the AD who's voting. In the past, routing protocols had to have 2 interoperable implementations. OSPF, etc are fairly complicated. Talked with Bill Fenner and may relax this to a case-by-case basis. Bill wrote a draft that makes the other RFC obsolete. For very complicated protocols, it makes sense. Forces is about as complicated, so would like to have 2 that work. Can be interpreted that 2 implementations can be one control plane one bearer plane. Would be hard to argue that we have any implementations using SCTP. Jamal: shouldnt be that hard. Have no problem letting TCP be mandatory, but not in the form of the current TCP TML. It is too complicated. Ross: Other ADs might think differently. Joel: If TCP TML isn't done, we need to finish it. Whatever is mandatory must be documented. SueHarris: With SCTP doc, one problem that has been occurring in other WGs, is interaction between 2 protocols. If you are going forward with SCTP, need to iron those out. Capwap did that, ended up re-writing a lot of drafts. Look at state machine from capwap, state machine from BGP, make it work. For the TCP piece, make sure these are cleaned up. Failovers, what happens when keys fail, etc. Jamal: thanks for the feedback 5) Evangelos Haleplidis (15-20 minutes) Implementation experience ece.upatras.gr University of Patras Department of Electrical and Computer Engineering Along with 2 professors What part was implemented Overcoming some challenges Questions * Need Flexnet: scalable, modular network architecture His part was to create a WLAN AP with dynamic service deployment capability, should be able to configure the forwarding path as well. At the time, draft was at version -06. LFBs: FEProtocolLFB FEObjectLFB IncomingLFB OutgoingLFB ClassifierLFB * Current project: Phosphorous www.ist-phosphorous.eu His part was to build token-based switch for traffic routing and packet identification. Code based on protocol draft -11. *Current implementation has 1 CE and 1 FE. FE contains mandatory LFB, Rx Tx LFBs TML: TCP Jamal: Is the FE a hardware-based? Yes, based on Intel IXP. *Protocol implemented: Association Heartbeats Set/Get *CE Basic CE functionality Incorporates a web service for sending commands Commands are processed in XML and translated into ForCES. *FE based on IXP enp2611 (no security) 2850 (with security) TBS and IXP coding done by Mihai Cristea (science.uva.nl) Token based switch *TBS FE can have 3 configurations, based on application type Entrance point of a packet: only TB Entrance point to an authorized network Internal change *Rx model based on model draft. TB model: TS model: has tuples to create tokens and compare them Counters to count bad tokens, good tokens. Event when bad token count exceeds a certain amount. Tx Model: Packet counter, needs to know which port it should send packets *Development Challenges: No hardware that is forces-compatible. Had to build APIs to send messages to hardware. Complex model components Dynamic protocol messages, many LFB selects, many commands, operations Need a way to de-serialize message from wire to validate correctness and make use of it. Protocol interface: web server. *First implementation (-06) done in Java. Pros: a little easier to code in Java. No pointers. Con: no system calls. *Second implementation (-11) done in C++ Pros: have system calls Con: pointers *Modeled components based on inheritance. *LFB component hierarchy: Component, Component_Byte, Compnent_Byte_Array Dense data and sparse data. To create more complex, re-use Component_Array *Protocol basic Messages Basic_TLV .......... ILV. Type, Length, data, list of next TLV. *Basic_TLV is superclass of LFBSelect_TLV *Decided to have 1 CE that would control multiple FEs, needed an API on which to issue commands. Used web services. Conceal ForCES model and protocol from programs. Connections of multiple programs into one Forwarding Element. Advertise API. ForCEG Architecture (not fully implemented) *Questions for the group How will ForCES be used by higher layer apps & to alleviate network services? What is relationship bewteen ForCES and netconf? Similarities/differences. *Joel: netconf is doing something conceptually very different. Netconf assumes human being changing device over there. Not what ForCES is doing. In ForCES, the CE is the brains of the router. Netconf notion is CLI. ForCES allows CE to modify the details of an FE. CE's can't be geniuses. Would like to just say "here is a policy" but it's going to take a lot to get that working. CE is the brain, but it's not the be-all and end-all of policy server. For different problems you would build different CEs. *Sue: You are asking why these two are different. From a research perspective: Data flows are different. Should look at work from Network Processor Forum. Look at different data flows. IPv4 API or IPv6 API of NPF. There were things you could do intelligently (split apart routes from next hops). Network configuration follows a different data flow. You can look at it as a database or an inline hierarchy. Those data flows for netconf can be optimized. If you need papers I have references. Data flow doesn't work as well. HW devices differ. 6) Evangelos Haleplidis (15 minutes) Demo (if there is time) University of Amsterdam 3 things: 1. 2 FEs with Ids 4 & 8 will associate with CE upon bootup Demonstrate simple token-based Network Access control with in-band signaling. Access to privileged and non-privileged domains. Steve casner: rembrandt 2 and 3 have different IP addresses? Jamal: he is demonstrating 2 different networks. SC: both have same destination address? When you change policy in the router, destination would remain the same? EV: just the demo 7) Jamal Hadi Salim (1-5 minutes) Wrap-up and Adjourn TCP vs. SCTP, will we talk about that online? Joel: list is the place to do it. Jamal: TCP has been sitting dormant for over a year Joel: we've got to finish something, we've got to make something mandatory. Avri: just submitted -13.