Last Modified: 2003-10-20
SSM is intended to be a short-lived and highly-focused working group.
The working group has two specific tasks:
1) A concise standards-track RFC that clearly defines the source-specific multicast model and its relation to RFC 1112 multicast. This document will specify of the host interfaces to be used for source-specific multicast, the rules that hosts, routers, and protocols must follow when allocating and using source-specific addresses. This document will serve as a reference to RFC authors designing protocols and host interfaces that implement SSM.
2) An informational RFC providing an overview of source-specific multicast. This document will serve as a starting point for parties interested in source-specific multicast.
Other SSM-related documents may be taken on as work items by other multicast working groups that have more specific expertise, including pim, mboned, and magma. For instance, a document describing the use of IGMPv3 for SSM has been adopted by MAGMA. The SSM working group chairs will cooperate with chairs of the related working groups and the Area Directors to determine the appropriate location of SSM-related documents that arise during the working group's lifetime.
|Aug 00||First meeting|
|Aug 00||Submit source-specific multicast model as internet-draft|
|Aug 00||Submit I-D for source-specific multicast|
|Sep 00||Reach consensus on source-specific multicast model and alloctate address space to source-specific multicast|
|Jan 03||Submit I-Ds on source-specific multicast model and alloctate address space to source-specific multicast to IESG for consideration as a Standards-track RFC|
|Jan 03||Submit I-D on source-specific multicast deployment to IESG for consideration as an Informational RFC|
|RFC3569||I||An Overview of Source-Specific Multicast(SSM)|
already.SSM wg chairs -------------------------------- Agenda bashing - Hugh Presentation - Admin scoping and SSM - Hugh beau williamson: what we are seeing more and more now is extension of 239/8 down into admin scopes inside the private address space, multiple limited scopes hugh: yes, some applies recursively as well. isidor: scoped range - you don't mean group range, right? hugh: not , a scoped range is a scoped set of channels, defined by source mask, destination mask, source and destination simultaneously, etc. beau: why would you put a filter on a stub region? hugh: for example, if an enterprise, not transiting anything, does not want information to leak out, e.g., CEO giving a speech. beau: misunderstanding definition of stub - thought that stub is like a multi-access network with hosts on it. hugh: no this is more of an AS sense of a stub, a much larger topological stub. isidor: about blocking joins, I think it would be more in line with the PIM spec if instead of ignoring joins, you actually store the joins but actually don't translate them into forwarding state. because eventually if you change the filter, you may want to use existing join state that you may have. hugh: yes. dino: ssm on 232/8 - is that assuming the type of routing protocol that will be used for those ranges. so if you are using a dense-mode protocol you cannot filter joins. hugh: if you are using dense-mode protocol at the boundary, then that is a good point, you have to filter the traffic. The draft says that you have to prevent the traffic from going out - either by filtering joins or filtering traffic. dino: so it will be nice for the spec to say that you can do control plane or data plane filtering. hugh: yes, out of curiousity, is anybody doing SSM with dense mode? hugh: some other alternatives not mentioned in the draft - includes allowing the address range to float in 232/8. a lot of entities need to know of this range. isidor: and you still need to the API to request a scoped address. hugh: yes, so this a property of any proposal. hugh: so how do you make this consistent. Another choice is to fix a range within 232/8. Cannot make it too small to avoid collapsing on a small set of ethernet addresses. hugh: comments?? toerless: would like to see the first option (above) to be considered as an alternative. We are not talking ssm-specific, but ipv4-specific. there is not much of a problem with allocating 239 range configured properly. that is much of the ssm we are seeing today. with the proposal, you have to understan how to correctly configure the filters. the normal approach of allocating an address range is simpler. would not want ssm to be restricted to 232/8. hugh: not suggesting not doing ssm outside 232/8, but there are certain ramifications, would not want the ietf to go down the path. beau: two things - one is the ability to use 232/8 as SSM or not; other is the use of filtering other than group-based. hugh: the draft actually addresses the second point. beau: it leads to a discussion of the second point. can you explain the group-based bi-directional boundary approach is inadequate, and we have to have the uni-directional, more elaborate filtering mechanism? what problem are you fixing. isidor: the bi-directional one breaks the transit case. hugh: the destination-based breaks the transit case; and the bi-directional breaks the case that you want to listen to a source outside your domain. beau: don't see how it is different from an ASM model when you switch over to a shortest path tree. if you have a domain boundary on a group address range, you are going to block either the data flow or the control packet flow from entering or leaving the boundary. This is already implemented, and it works. hugh: I decide that I am putting all my company stuff on an internal source 232.239, and decide to block it. Now there is an external source transmitting interesting stuff, and I don't want to block it from coming in. pekka: don't see a problem in the transit case. don't see why a transit AS would want to block. other problem - how to do it v6, because v6 already has scoping, so would this be useful? two issues - whether we want to do something like this for v6, and do we want to be able to scope ssm v6 multicast with the source and destination in global scope. hugh: if you want to do the latter, then you have to do something like this p roposal. dave thaler: about the two proposals. if the first one requires additional protocol stuff, then hugh's proposal is better. the problem with the current draft is title - should say ipv4. hugh: could apply to v6. dave: don't want it to apply to v6. other thing - there is nothing that says that it is illegal for the app to use the include mode in the 239 range. brian haberman: like this proposal better. gets rid of the machinery. for v6, we are better off using the scope in the multicast address. so change the title, no other problem. john meylor: as long as the app can use include mode in 239 range, then that is the most important component brought out in the draft, because after that you can do pretty much anything in your own admin domain. key thing to specify that if you are doing anything outside of 239 in a transit networl, then you allow for transit to pass through. toerless: scope identified by group range is simpler, hugh's option is doable but complex. it is doable, academically interesting. don't need it for v6. this pr hugh: what do you want? toerless: don't want anything coming out of this process that is more complex. hugh: source filtering only in transit case, otherwise always destination. what would you do? toerless: a draft should outline all the alternatives for scoping for v4 multicast, without expressing a preference for any one. would go for 239/8 sub-ranges that are allocated by local authorities. dino: if you had group range filtering only, would that make you happy? toerless: yes. dino: just say you can optionally do source-based filtering as well. john meylor: the important point here - whatever range we scope on, when you arrive on a transit network, you can predict your behavior. in the scoped domain, as long as you can use include mode in the application, you can pretty much do what you want. nothing that the ietf has to dictate about that. nothing that precludes toerless point other than if you are going to recommend that within the 232 range you have scoped behavior, then you have to make it clear to the transit provider that if they are going to apply scoped behavior on the 232 range, they have to allow for transit. and that is what dictates the uni-directional filter. hugh: agreed. pekka: seems like if we do ssm inside 239, we will also have to leave the option to specify in the protocol stack where we want to do ssm. would be much better to glue those in when you design the protocol. an option may be to use 231, will that be better. hugh: well we could take half of 232. toerless: for v4, one additional scope for a private enterprise,maybe that is a simple compromise to give leeway to people that design protocols and cannot be bothered with the ssm range. not a strong argument, but if that is what the ietf wants... hugh: not just the protocols, reduces configuration burden. toerless: limiting the scope of the application is a primary security concerns of every scoped definition. so putting effort into that is considered a part of the securities definition of a network. so there is not that much of a problem getting work done on that as opposed to other work on multicast. beau: we are not gaining anything. the only advantage is that we have two range - inter-domain 232/8 always transit. the other is a well-known for ssm but private. don't care where it comes from. still have the problem of configuring the network. hugh: reduces the problem of where to configure for ssm behaviour. beua: no it doesn't because inside an enterprise you will have different scopes, and those boundaries are going to be arbitrary. so there is a lot of admin going on in terms of where the boundaries. hugh: but this avoids configuring other things like RPs, DRs. this is not necessarily to ease the configuration of boundaries. beau: so, lock it down into two - inter-domain and intra-domain (carve up the way you want) and then use group-based boundaries. unknown (used to be an operator): don't mess with 239, because it will be nice to sketch out a scenario where a router gets shipped out to an enterprise which by default would have useful behaviour, e.g., 239 is admin scoped, etc. i.e., something reasonable out of the box, if the enterprise wants something more clever, they can do it. toerless: how about just to be able the same scope boundaries in a dual mode network simply use the high-order 4 bits of the third byte to have the same scope levels as an ipv6 so that you can use the same boundaries when you will be building an enterprise network hugh: guess you are cutting your address space down. toerless: how many channels do you need? hug: there is an ethernet collision issue. toerless: well, the ietf made a decision about v6. tradeoff between simplicity and freedom. boundaries not that simple. dave thaler: half convinced, half not that there is an issue. what do we expect the apps to do? first, the app has to pick an address G and there has to be a filter in the router. which happens first? hugh: filter in the router. dave : in that case, how does the app pick an address? hugh: either the user has to know, CLI or on the box or something. Or you have a protocol mechanism. dave: don't like either of those. that is why it is good to pick a sub-range of 232/8 or 239. hugh: but it is not good as an application user to rely on scoping simply because the ietf says so. dave: true. if you use 231/8, you can use the same subnetting scheme, which is what ipv6 is doing for different types of prefixes. your breakdown within the /8 could be the same. what is the scoped divisions for 239 - there is a protocol for that. 50% convinced of toerless and beau's point. in your proposal, you _have_ to do coordination. hugh: anyone has a sense how it is difficult to get a /8 for multicast. toerless: just worried that if it does not say clearly that other address ranges must be supported to allow for scoping, then this may fall over. in the end, there may be apps that can only do ssm with additional protocols in 232. bit paranoid, but has been known to happen in the past. hugh: is the concept of a /25 too hard? can we split the space in half? would be backward compatible with anyone doing ssm today. tom: thinking of deployment, if you want to go to admin scoped you have to configure border routers. already done in 239 range, so let people do what they want there. hugh: gotta worry whether things like msnip - would it work in 239 space? tom: we have the ability to configure additional range of ssm space - then we have to configure all routers. beau; but you already have a problem like that today. you still have people building ASM/bidir admin scoped ranges inside the 239 range. so how do communicate and configure the application so that it uses the appropriate scoped range address for (1)what the app was designed to do (2) what the network administrator wants the scope to be for that particular app. so...pick some ranges in 239 so that you can do the same. you have to configure the routers to let them know which range within 239, which you have to do at the boundaries. so it is a part of the configuration. louis: but the no. of boundaries is smaller than all routers. toerless: ssm in ip4 with admin scoping must have all the benefits of global scope, not partial suppirt. End of presentation - admin scoping and SSM. Presentation: SSM architecture draft and IPR - Hugh hugh: possible next steps for ssm - comments?? toerless: go forward. to what degree does the risk factor also apply to other protocols - e.g., igmpv3. or take PIM - if you get an (S,G) from IGMP, does it fall under the IPR. and that could be ASM not even SSM. hugh: could be interpreted to cover any case where receiver specifies source. toerless: so include mode in igmpv3. hugh: yes. alex: if it is standardized, then licenses will be available. does not say what if it is not standardized. tom: if they are not claiming igmpv3 and pim, then why this? hugh: they are only required to notify if they know specific technology is IPR-impacted. tom: by not notifying, they are giving up their rights. hugh: not true. pekka: they are not required to give any terms or disclose anything unless they take par in the deliberations reg. the technology. not sure if people from apple have been talking about igmp or ssm, etc. They are probably giving it away for free, they don't have to. The reason that they are doing this for ssm not igmp is that they picked something source-specific. Personal belief: must not go for proposed standard. try to gather more information. try to get royalty-free, see later how to proceed. hugh: approached apple, not very receptive. bill fenner: what is different from if apple had waited until after the rfc came out. pekka: not much of difference. qn here : now that we know about it, should we do something. depends on how much of backchannel with apple. dino: claims are very general - e.g. transmitting data with a computer, joining group. patent was filed in 94, first pim rfc in 97. bill: options are: investigate validity or force them to license. only judge can judge validity. it is a judgement call, not for us. so remove validity from the table. not going to say that this patent is invalid. on licensing tierms, we have no leverage. dino: apple lawyers are not stupid - have to go after ciso, microsoft. bill; they don't have to go after anyone, pick and choose what they want to enforce. can't see any forward progress with step 2 (checking validity). pekka: is there any chance of prior art? bill: very little, based on the timing. hugh: maybe we can dig up some emails? bill: prior art in itself does not do anything. it is the opinion of the judge taking prior art into account. brian haberman: only choice seems 1. so go on, and see what they do. hugh: need two implementations to fo to draft standard. need license for implementations, at which point the decision will be automatically made. john meylor: go forward. toerless: can the text be changed to be less specific to the IPR. hugh: not likely to work. bill: is there anyone who would absolutely not implement it if there was IPR onit? it is in bsd. <no response> pekka: would not put it in linux. unknown: has anyone licensed? bill: don't know. apple supports open source. hugh: incredibly strong licensing statement for W3C. pekka: regarding w3C, members of w3C have been arm-twisted to provide royalty-free statements, the process here is different. alex: to move forward, ask the room: who believes that the group is ready to make a decision, and who believes that we need more information and discuss at the next meeting. john meylor: nothing illegal to move it to proposed standard. what needs to be thought about is whether people would want to implement the draft after that? do people think there is anything wrong with the document? else, go forward. hugh: who thinks we need more time 2 hands hugh: who thinks we should go forward numerous hands hugh: who thinks we have enough information to decide not to go forward. none. hugh: so we will take this discussion to the