210 likes | 335 Views
Internet Media Guides – Update and Open Issues –. Yuji Nomura, Pekka Luoma, Rod Walsh IETF-58, MMUSIC, 14.Nov.2003. Internet Media Guides – Requirements Update –. Yuji Nomura IETF-58, MMUSIC, 14.Nov.2003. draft-ietf-mmusic-img-req. Current: draft-ietf-mmusic-img-req-00.txt
E N D
Internet Media Guides – Update and Open Issues – Yuji Nomura, Pekka Luoma, Rod Walsh IETF-58, MMUSIC, 14.Nov.2003
Internet Media Guides – Requirements Update – Yuji Nomura IETF-58, MMUSIC, 14.Nov.2003
draft-ietf-mmusic-img-req • Current: draft-ietf-mmusic-img-req-00.txt • A lot of changes from previous • draft-nomura-mmusic-img-requirement-01.txt (individual submission) • We will submit draft-ietf-mmusic-img-req-01 soon
draft-ietf-mmusic-img-req-00.txt Changes (1/3) • 1. Introduction • Background and Motivations (new) • 3. Problem Statement (new) • Moved and shortened from old framework draft • 4. Requirements • 4.4.2 Support for Intermittent Connectivity • The system MUST enable IMG receivers with intermittent access to network resources
draft-ietf-mmusic-img-req-00.txt Changes (2/3) • 4.4.3 Congestion control • Internet-friendly congestion control MUST be provided. • 4.5 IMG Descriptions • IMG metadata MUST be interoperable regardless of the transport protocol and network used to get it • IMG metadata MUST be structured to enable fragmentation (e.g. of the global set of metadata) • IMG metadata SHOULD support ‘delta’ syntaxes for efficient messaging following small changes to metadata
draft-ietf-mmusic-img-req-00.txt Changes (3/3) • 5. Security Considerations (many changes) • IMG Authentication and Integrity • Privacy • Access Control for IMGs • Denial-of-Service attacks • Replay Attacks
Next steps and open issues For draft-ietf-mmusic-img-req-01.txt • Numbering requirements • Modify terminology for consistency • Clarifications requested • Many more receivers than senders • Senders are continually connected (receivers are not) • Tradeoff between customization and scalability • WGLC on the horizon
Internet Media Guides – Requirements Update – Questions???
Internet Media Guides – Framework Update – Pekka Luoma IETF-58, MMUSIC, 14-Nov-2003
draft-nomura-mmusic-img-framework • Current: draft-nomura-mmusic-img-framework-02.txt • Previous • draft-nomura-mmusic-img-framework-01.txt (individual submission) • We will submit draft-ietf-mmusic-img-framework-00 soon
draft-nomura-mmusic-img-framework-02 Changes (1/2): • 3. Use Cases Requiring IMG Framework • Content-oriented use cases (new) • 6. Applicability of Existing Protocols (new) • New section (requested/agreed in Vienna) • 6.1 Limitations of Existing Protocols • 6.2 Existing Protocol Fit to the IMG Framework Model • 6.3 Outstanding IMG Mechanism Needs
draft-nomura-mmusic-img-framework-02 Changes (2/2): 6.3 Outstanding IMG Mechanism Needs • Multicast Transport Protocol • Maybe ALC-based • Usage of Unicast Transport Protocols • HTTP, SIP events, … • The Metadata Envelope • New/single term for an existing framework model concept • Gives independence from transport protocol and metadata format • Baseline Data Model Specification • Informative only, not MMUSIC/IETF standardized
draft-ietf-mmusic-img-framework Next steps and open issues (1/3): • Editorial - clarifications, corrections of typos • Terminology: IMG, IMG metadata, IMG delivery, … • New section for what’s in IETF scope - separated from outstanding IMG needs section • In scope: Transport protocols, transfer envelope • Out of scope: Data models, application specific metadata
draft-ietf-mmusic-img-framework Next steps and open issues (2/3): • IMG Metadata identifier • Probably a URI in all cases • Differences between complete, delta and pointer: • Same id, different ‘data type’ – how to signal data type? • Different syntax between complete and delta • IMG metadata can refer to (and possibly locate) related metadata delivered over other transport channels and sessions, using the same locator/identifier as in the metadata envelope • I.e. unify the identifier/locator for both metadata envelope and IMG metadata (suggestion for anyone specifying metadata)
draft-ietf-mmusic-img-framework Next steps and open issues (3/3): • Submit revised version • WGLC target: December
Internet Media Guides – Framework Update – Questions???
Internet Media Guides – Some Other Technical Issues – Rod Walsh IETF-58, MMUSIC, 14.Nov.2003
Design Choices • Multicast Transport Protocol • ALC/FLUTE is a very good candidate • Subscribe (unicast) • SIP and SIP events • Metadata Envelope • a. XML file / wrapper • b. Header extension of transport protocols • Allow both methods? Or not? • Data Types and Channelisation • Could correlate data type and transport channel, e.g. “pointer-only channel” • Could divide delivery over multiple channels • Multicast multi-layer congestion control usage • Both unicast and multicast channels could be employed
Middlebox Authentication & Integrity Issue • A middlebox may combine, add, modify and remove metadata • The original sender signature will be invalidated in some cases • Solutions: • Trusted (by sender) middlebox – re-signs using original authority • Inter-domain trust issues • Middlebox request to sender for new signing (post-modification) • Middlebox just signs new and changed metadata • Requires appropriately small fragmentation of metadata • Possibly: changeable metadata as small fragments, and stable metadata as large fragments (most applications we have discussed do not use a middlebox) +----------+ +----------+ | IMG | | IMG | | Sender |---- ---->| Receiver | +----------+ \ / +----------+ \ / . \ +-----------+ / . . -->|IMG |----- . . -->|Transceiver| \ . / +-----------+ \ +----------+ / \ +----------+ | IMG | / ---->| IMG | | Sender |---- | Receiver | +----------+ +----------+
Internet Media Guides – Other Technical Issues – Questions???