IP over IEEE 802.16 Networks Working Group (16ng) o 67th IETF - San Diego, US o 0900 - 1130 Morning Session II, Grande Ballroom C Tuesday, November 7, 2006 ==================================================== Special thanks to DJ Johnston (note taker) and Alexandru Petrescu (jabbor scriber). Daniel Park has slightly modified the minutes. ==================================================== [Q: Question / A: Answer / C: Comment ] Agenda bashing, No changes WG report - updated milestone - a new deliverable Document status - draft-ietf-16ng-ipv6-link-model-analysis (WGLC expired) - draft-ietf-16ng-ps-goals (WGLC expired) - draft-ietf-16ng-ipv6-over-ipv6cs (in WGLC) Interim meeting in Mannheim overview Gabriel: Consesus call on prefix model (point-to-point model) IP over eth CS Some more knowledge on how vlans & bridging works required IPv4 over IPv4CS model not discussed --- Agenda: 802.16 Liasion (DJ Johnston) 802.16 status and relevant activities --- Agenda: 16ng Problem Statement (Daniel Park) Doesn't consider problem work a success. No comments or feedback. 10 people claimed to have read document on show of hands. Request for comments on 16ng mailing list. Wants to start working on document again on the mailing list. In parallel, chairs will look for some of reviewers for the document. --- Agenda: Link Model Analysis for 802.16 based networks (Dave Thaler) Shared prefix model (NBMA model) Point to point link model Ethernet like model. Q)DJ Johnston: questioned the picture. Agreement that each MS has separate port to bridge. Dormancy is orthogonal to link model. So not a factor in choice of link model. Limiting Multicast/Broadcast. Desire to do so because of the power requirements. Recommends use of MLD snooping rather than other DAD optimizations for DAD. IGMP/MLD snooping quick tutorial. Mature spec RFC4541 covers this. Q)Max Riegel: Questions all hosts multicast. A)Dave Thaler: refers RFC3810.Further consider MLD snooping. Q)Myungki Shin: Not design team output ? A)Dave Thaler: design team is done, work is now with the WG. A)Chair: yes, but WG will consider how to deal with this. Q)Max Riegel: Are we looking at proxy summarization? Why only snooping? A)Dave Thaler: Potentially good, but not addressing specific problem being considered. Not saying its good or bad. looking at proxy summarization can be done. Model recommends Ethernet CS Ethernet like model AR IPv6 CS Point to point model C)DJ Johnston: Comments on terminology of IPv6 CS. Correct is Packet CS, IP Specific Subpart with IPv6 classifier. Chair requests more input on terminology. C)Daniel: Terminology should be more clarified in PS document. --- Agenda: IPv6 over IPv6 CS (Basavaraj Patel) Draft just released weeks ago. Specifies addressing and operations of ipv6 over ipv6cs. Recommends assignment of unique prefix(es) for each host. Recommends point to point link between the host and AR. Not shared prefix. MAC is connection oriented and the convergence sublayer is a part of the MAC itself. Service appears as a point to point link. So Looking at runnning ipv6 over that CS as a point to point link. Possible network models discussed. Host or BS can trigger the establishment of transport connection. Then ipv6 link is up. Each MS is on a separate subnet. one or more /64 prefixes should be assigned to a link which consists of only and AR and an MS. Unique prefix allocated to a host and prefix is advertized on RA message. Neighbor discovery simpler with point to point link model, so is as per RFC2461. No change to IPv6 specifications required. Recommends prefix is advertised with the L-bit set. Q)Jari Arkko: questions raising the upper limit on RA and referencing DNA doc. No referencing DNA solution drafts in this document. Addressing as per RFC2464 privacy extensions as per RFC3041 DAD as per RFC2461 & RFC2462 C)Dave Thaler: There are other ways, DHCP, static config, etc. But not specific to IPv6. So proposed method is a method, not the method. Stateless adress autoconf as per RFC2461, 2462 Received some comments, would like more. Will align terminology. But will explain more specific terms, like transport connection in the draft. MTU would be up to 2048. but recommend using the MTU from the RA if present. Reference RFC3633 as means for obtaining prefixes. C)Dave Thaler: Not sure that's necessary. No different to any other thing, so not specific to 802.16, is out of scope. C)Suresh Krishnan: Need to Explicitly describe the format of the SLLAO & TLLAO. C)Dave Thaler: remove references to prefix discovery draft. Similar comment from others. Recommend comments as fast as possible. Last call still open. C)Jari Arkko: Doc needs additional review. It's in pretty good shape, but needs more review by WG. --- Agenda: IP over ethernet CS (Max Riegel) Not all content yet in current draft due to time constraints. Conf call near to publication date. Issues compared to wired ethernet. Shared tranmission resource. Don't want to waste tranmission BW. Terminal power critical. Waking to receive a couple of packets highly wasteful. Link model similar to IP CS model. A single bridge is assumed for the whold access network. Q)DJ Johnston: Is AR aware of 802.16 being behind the bridge. Q)Dave Thaler: Is single bridge behind BSs discussed in the draft. Is two BSs behind a bridge 1 or 2 accness networks. Distributed bridges make it hard to test for no match in all bridges. Single bridge makes it easy. C)Dave Thaler: But it's easy to flood. C)Dave Thaler: One bridge knows, another doesn't. So bridge that doesn't needs to flood. Public access scenario.. Peer to Peer between neighbours not available by the bridge. All traffic forwarded to the AR by the bridge. VLAN Scenario. Peer to Peer comms may be enabled within particular VLANs. Allows the creation of L2VPNs. 2 I-Ds for IPv4 and IPv6. Hongseok Jeon to merge into one doc. Design call Oct 20th for IP over ethernet CS. draft-riegel-16ng-ip-over-eth-over-80216-01.txt. combined v4 & v6. refined network model. Multicast using multiple unicasts. Not MBS. Standard learning bridges with static filtering entities out of authentication process. RFC4541 for multicast snooping bridging. Extended ICT supporting multiple IP addresses per host. ND relay tied to ICT. C)Dave Thaler: Don't need text for privacy extentions. A)Max Riegel: Need to know which address on which port. C)Dave Thaler: No different to normal addresses. A)Max Riegel: No different but they must be learned. C)Dave Thaler: Agrees don't need to reference RFC3041. RA does this. A)Max Riegel: Requests some time to consider RFC3041 (Privacy extentions) RA handling MTU Considerations Security section C)Dave Thaler: Don't think RA handling leads to any code change in RA implementation. Q)...: Don't understand target of language limiting RAs to not invalidate timestamps. Table of Contents Conclusions. ID on v4 and v4 other eth-cs exists. Next steps. Adoption as WG item. Feedback from switch manufacturers desired. Chair: Show of hands on making WG. Will continue process on reflector. ----------------------------------------- Agenda: IPv4 over 802.16 IP CS (Daniel Park) No draft Introducing the work to the WG. Layering. Wimax network architecture. Packet format. Address assignment using DHCP. C)Dave Thaler, Ken Young: DHCP doesn't require 802.16 specific. So doesn't need to be in draft. C)Ken Young: Option 86 in DHCP to allow requestor to be identified in DHCP request. May want to reference it in the draft. ARP not required for IPv4 CS as MAC address is not used for data path. Q)Dave Thaler: Why proxy ARP if it's a point to point A)Daniel: It's the 802.16 connection that is point to point, not IP. Also, this concern should be clarified in this document in conjunction with wimax release. --- Chairs: looking for reviewers on v6ops 16-scenario document. --- Closed