2.5.10 Source-Specific Multicast (ssm)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Chair(s):
Hugh Holbrook <holbrook@cisco.com>
Supratik Bhattacharya <supratik@sprintlabs.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Bill Fenner <fenner@research.att.com>
Mailing Lists:
General Discussion: ssm@ietf.org
To Subscribe: ssm-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/ssm/current/maillist.html
Description of Working Group:
The purpose of the SSM working group is to define source-specific multicast in order to provide unambiguous semantics to the designers of the protocols and host interfaces used in conjunction with source-specific multicast.

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.

Goals and Milestones:
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
Internet-Drafts:
  • - draft-ietf-ssm-arch-04.txt
  • Request For Comments:
    RFCStatusTitle
    RFC3569 I An Overview of Source-Specific Multicast(SSM)

    Current Meeting Report

    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 

    Slides

    None received.