1 / 21

Internet Media Guides – Update and Open Issues –

This document discusses updates to the Internet Media Guides, specifically focusing on the requirements and frameworks outlined during IETF-58. Key changes in draft-ietf-mmusic-img-req include new problem statements, requirements for intermittent connectivity, and enhanced metadata interoperability, while addressing security considerations. The framework update introduces new use cases and analyzes existing protocols, aiming to clarify terminology and outline next steps. Readers are invited to engage with the proposed changes and contribute to the ongoing discussions.

nevaeh
Download Presentation

Internet Media Guides – Update and Open Issues –

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet Media Guides – Update and Open Issues – Yuji Nomura, Pekka Luoma, Rod Walsh IETF-58, MMUSIC, 14.Nov.2003

  2. Internet Media Guides – Requirements Update – Yuji Nomura IETF-58, MMUSIC, 14.Nov.2003

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. Internet Media Guides – Requirements Update – Questions???

  9. Internet Media Guides – Framework Update – Pekka Luoma IETF-58, MMUSIC, 14-Nov-2003

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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)

  15. draft-ietf-mmusic-img-framework Next steps and open issues (3/3): • Submit revised version • WGLC target: December

  16. Internet Media Guides – Framework Update – Questions???

  17. Internet Media Guides – Some Other Technical Issues – Rod Walsh IETF-58, MMUSIC, 14.Nov.2003

  18. 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

  19. 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 | +----------+ +----------+

  20. Internet Media Guides – Other Technical Issues – Questions???

  21. Internet Media Guides – Update and Open Issues – Thanks !!!

More Related