Update on mobility services framework design document
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Update on Mobility Services Framework Design Document PowerPoint PPT Presentation


  • 61 Views
  • Uploaded on
  • Presentation posted in: General

Update on Mobility Services Framework Design Document. Gabor Bajko, Subir Das, Nada Golmie, Telemaco Melia, JC Zuniga. IETF-72, Dublin, Ireland. Outline. Update on draft-ietf-mipshop-mstp-solution-05 Update of draft-ietf-mipshop-mos-dhcp-options-04

Download Presentation

Update on Mobility Services Framework Design Document

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Update on mobility services framework design document

Update on Mobility Services Framework Design Document

Gabor Bajko, Subir Das, Nada Golmie, Telemaco Melia, JC Zuniga

IETF-72, Dublin, Ireland


Outline

Outline

  • Update on draft-ietf-mipshop-mstp-solution-05

  • Update of draft-ietf-mipshop-mos-dhcp-options-04

  • Update of draft-ietf-mipshop-mos-dns-discovery-01

  • Few words about draft-stupar-dime-mos-options-00


Terminology

Terminology

  • MoS – Mobility Services

  • MIH – Media Independent Handover

  • MIHF – Media Independent Handover Function

  • MSTP – Mobility Services Transport Protocol

  • MSFD – Mobility Services Framework Design

  • MoSh – Mobility Services at Home network

  • MoSv – Mobility Services at visited network


Draft ietf mipshop mstp solution summary

Draft-ietf-mipshop-mstp-solution: Summary

  • ID status

    • Most of the AD review addressed

      • Next few slides

      • Draft v05 already reflects these changes

    • Few remaining issues from AD review

      • Back-off retransmission

        • Gorry’s comment on backoff mechanism was already included in version 05 (Ref: Gorry’s email from 8/6/2008)

      • DHCP Authentication

        • Link layer security clarification

      • Integrated scenario support (NAS/DHCP)

        • Need to gather WG consensus to finalize the document

    • Additional issue

      • Number of Ports for MIH Services

        • Driven by implementation experience in Rogers, Vodafone networks


Draft ietf mipshop mstp solution contd

Draft-ietf-mipshop-mstp-solution (contd..)

Issue# 1: The assumption about MoS location

  • Comment: Is there a need to state that ES/CS is more likely to be associated with a visited network than home?

  • Modified Text: (Section 3.3)

    • This document does not make any assumption on the location of the MoS (although there might be some preferred configurations), and aims at flexible MSFD to discover different services in different locations to optimize handover performance. MoS discovery is discussed in more detail in Section 5.


Draft ietf mipshop mstp solution contd1

draft-ietf-mipshop-mstp-solution (contd..)

# Issue 2: MoS configuration

  • Comment: Text needs to be written in a much more detailed and specification-like manner

  • Remedy:

    • Text reworked and modified in Section 4


Draft ietf mipshop mstp solution contd2

draft-ietf-mipshop-mstp-solution (contd..)

Issue #3: MoS authorization

  • Comment: Can we end up in a situation where DHCP discovery delivers a server address which refuses to talk to us, for instance?

  • Modified text: (Section 5)

    • In case future deployments will implement authorization policies the mobile node should fall back to other learned MoS if authorization is denied.


Draft ietf mipshop mstp solution contd3

draft-ietf-mipshop-mstp-solution (contd..)

Issue #4: Scenario 2 (DHCP + DNS)

  • Comment: A lot of complexity

  • Modified text: (Section 5.2)

    • Text reworked and modified in Section 5.2


Draft ietf mipshop mstp solution contd4

draft-ietf-mipshop-mstp-solution (contd..)

Issue #5: MoS in 3rd party networks

  • Comment: Can this document point to specific attributes defined in IEEE that would carry such information?

  • Modified text: (Section 5.3)

    • IEEE 802.21 defines information elements such as OPERATOR ID and SERVICE PROVIDER ID which can be a domain name. Text reworked and modified accordingly in Section 5.3


Draft ietf mipshop mstp solution contd5

draft-ietf-mipshop-mstp-solution (contd..)

Issue #6: MIH MoS capabilities

  • Comment: The document does not talk about how servers know the capabilities of clients that send event/command services to. Is this a part of the IEEE definitions, and you subscribe to a particular event stream? In any case, the document should talk about this and point to the relevant other specifications where needed.

  • Added text: (Section 6)

    • Once the Mobility Services have been discovered, MIH peers may run a capability discovery and subscription procedures as specified in IEEE 802.21 if not discovered via either DNS or DHCP.


Draft ietf mipshop mstp solution contd6

draft-ietf-mipshop-mstp-solution (contd..)

Issue #7: MoS message framing

  • Comment: The document is very silent on how MIH messages are carried on a given transport protocol. At the very least the draft should indicate that no extra framing is needed because IEEE specs already contain a length field.

  • Modified text: (Section 4)

    • The usage of transport protocols is described in Section 6 and packing of the MIH messages does not require extra framing since the MIH protocol defined in IEEE 802.21 already contains a length field.


Draft ietf mipshop mstp solution contd7

draft-ietf-mipshop-mstp-solution (contd..)

Issue #8: MIH message size/fragmentation

  • Comment: be more specific about MIH message size/fragmentation

  • Remedy:

    • Text reworked and modified in Section 6.1


Draft ietf mipshop mstp solution contd8

draft-ietf-mipshop-mstp-solution (contd..)

Issue #9: TCP and fragmentation of MIH messages

  • Comment: True, TCP can split the message, but is this really the cause of delay. If one uses the PUSH bit, then the records should be sent, even when no more data follows?

  • Added text: (Section 6.1)

    • The use of the PUSH bit can alleviate this problem by triggering transmission of a segment less than the SMSS.


Draft ietf mipshop mstp solution contd9

draft-ietf-mipshop-mstp-solution (contd..)

Issue #10: Token bucket parameters

  • Comment: I think this commentary effectively says very little, and so leaves it for operators to choose to do what they like. I'd suggest this is not good practice. It seems to recognize a problem, but be unwilling to address it.

  • Modified text: (Section 6.2)

    • Recommendations for token bucket parameter settings are as follow:

      • If MIHF knows the RTT, the rate can be based upon this

      • If not, then on average it SHOULD NOT send more than one UDP message every 3 seconds.


Draft ietf mipshop mstp solution contd10

draft-ietf-mipshop-mstp-solution (contd..)

Issue #11: Back-off retransmissions

  • Comment: So, is the UDP retransmission backed-off at all, as recommended in: http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines-07 - If the number of retransmissions is limited, what specifies this limit?

  • Modified text: (Section 6.3)

    • The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s. No backoff mechanism is specified.


Draft ietf mipshop mstp solution cnt ed

draft-ietf-mipshop-mstp-solution (cnt’ed)

Issue #12: Keep alive messages

  • Comment:This is too vague.

  • Added text: (Section 6.4)

    • Re-registration or Event indication messages as defined in IEEE802.21 MAY be used for this purpose.


Draft ietf mipshop mstp solution cnt ed1

draft-ietf-mipshop-mstp-solution (cnt’ed)

Issue #13: Security recommendation on IPsec

  • Comment: I do not see a particular requirement for IPsec here, why do we need to include it?

  • Suggested Remedy:

    • Removed recommendation for IPsec from the document


Draft ietf mipshop mstp solution cnt ed2

draft-ietf-mipshop-mstp-solution (cnt’ed)

Issue #14: Security recommendation on TLS/DTLS

  • Comment: The explanation on how to use TLS and DTLS seems thin. Is there something to be said about what type of certificates or infrastructure is needed, what modes of operation are allowed, etc?

  • Remedy:

    • Text reworked and modified in Section 8


Draft ietf mipshop mstp solution remaining issues from ad review

Draft-ietf-mipshop-mstp-solution: Remaining Issues from AD review

Issue #1: Back-off retransmissions

  • Comment: In Gorry's review he pointed out that the UDP usage guidelines document recommends an exponential back-off mechanism. The mstp draft deviates from this, and I'm not sure its appropriate to do so. Note that the guidelines had only a recommendation, not a requirement. But its not clear that you actually want to avoid an exponential back-off. Its easy to think of situations (such as the base station going down) where there would be a significant amount of retransmission traffic from a large number of hosts.

  • Suggested Remedy:

    • Already addressed (Issue #: 11)

      • Gorry’s comment: “Sounds fine (10 seconds seems large enough to me). I suggest you add your text.”


Draft ietf mipshop mstp solution remaining issues contd

Draft-ietf-mipshop-mstp-solution: Remaining Issues Contd..

Issue #2: DHCP authentication

  • Comment: I think the overall recommendation is good, but practically no one is going to deploy RFC 3118. With this in mind, I would like to see the above paragraph explain in more detail the security implications of relying on link layer security.

  • Suggested text (colored):

    • In the case where DHCP is used for node discovery and authentication of the source and content of DHCP messages is required, network administrators SHOULD use DHCP authentication option described in [RFC3118], where available or rely upon link layer security. This will also protect the DHCP server against denial of service attacks since [RFC3118] provides mechanisms for both entity authentication and message authentication. In case where DHCP authentication mechanism is not available administrators may need to rely upon underlying link layer security. In such cases the link between DHCP client and server may be protected but the source and DHCP messages can not be authenticated unless there exits a security binding between link layer and DHCP layer.


Draft ietf mipshop mstp solution remaining issues contd1

Draft-ietf-mipshop-mstp-solution:Remaining Issues Contd..

Issue #3: Roaming MoS scenario

  • Comment: But the big question for me was whether it is appropriate to employ DHCP-AAA binding so that per-MN information can be provided. I realize that we have done it once in the context of the Mobile IP bootstrapping work. But frankly, that sets a very high bar for deployment in a given access network and introduces dependencies and complexity that is undesirable. In general, if every application that wants to avoid configuration needs to have special support in DHCP relays, it becomes very hard to deploy anything new.

  • Suggested Remedy:

    • See next few slides and let’s discuss


Integrated scenario current state

Integrated Scenario: Current State

Visited | Home

|

|

+-------+ | +-------+

| | | | |

|AAAV |-----------|--------|AAAH |

| | | | |

| | | | |

+-------+ | +-------+

| |

| |

| |

| |

| | +--------+

| | | |

| | | MoSh |

+-----+ +------+ | +--------+

+----+ | | |DHCP | |

| MN |------| NAS/|----|Server| |

+----+ | DHCP| | | |

|Relay| | | |

+-----+ +------+ |

|

AAAv -- Visited AAA

AAAH -- Home AAA

NAS -- Network Access Server

Very similar to the MIP6 integrated scenario

Convey MoS information to the

NAS during network authentication

Store the information into the DHCP relay

Provide the MN with the assigned MoS

(network based) during IP address

Configuration

Do we want a method to configure MNs

in visited networks with (MoS) services

provided in the home network?


Integrated scenario approach i

Integrated Scenario: Approach I

Visited | Home

|

|

+-------+ | +-------+

| | | | |

|AAAV |-----------|--------|AAAH |

| | | | |

| | | | |

+-------+ | +-------+

| |

| |

| |

| |

| | +--------+

| | | |

| | | MoSh |

+-----+ | +--------+

+----+ | |

| MN |------| NAS | |

+----+ | | |

+-----+ |

AAAv -- Visited AAA

AAAH -- Home AAA

NAS -- Network Access Server

Convey MoS information to the

NAS during network authentication

NAS delivers the MoS information via link

layer or other mechanisms that are out of

scope of this document

Note: It does not provide a complete solution

since there will be no IETF specific solution

to deliver the MoS information from the NAS

to the MN


Integrated scenario approach ii

Integrated Scenario: Approach II

Visited | Home

|

|

+-------+ | +-------+

| | | | |

|AAAV |-----------|--------|AAAH |

| | | | |

| | | | |

+-------+ | +-------+

| |

| |

| |

| |

| | +--------+

| | | |

| | | MoSh |

+-----+ +------+ | +--------+

+----+ | | |DHCP | |

| MN |------| NAS/|----|Server| |

+----+ | DHCP| | | |

|Relay| | | |

+-----+ +------+ |

|

AAAv -- Visited AAA

AAAH -- Home AAA

NAS -- Network Access Server

  • - This option is currently in the Annex of v05 and

  • can co-exist as an option in addition to solution I

  • - Conveys MoS information to the

  • NAS during network authentication

  • Store the information into the DHCP relay

  • - Provide the MN with the assigned MoS

  • (network based) during IP address

  • Configuration

  • Note: This is not specific to MSTP and MoS

  • discovery, seems to be a general issue

  • within IETF


Draft ietf mipshop mstp solution remaining issues contd2

Draft-ietf-mipshop-mstp-solution:Remaining Issues Contd..

Additional Issue: Number of Ports

  • Problem: Current specification mandates the use of three different ports, keep-alive messages for NAT traversal on three different ports are an issue. Too many messages to send.

  • Suggested Remedy:

    • Update the ID and register one default port number with IANA for all services


Update of draft ietf mipshop mos dhcp options 04

Update of draft-ietf-mipshop-mos-dhcp-options-04

  • Version -04 is available at http://tools.ietf.org/html/draft-ietf-mipshop-mos-dhcp-options-04

  • Changed from multiple DHCPv4 options to one DHCPv4 option and added several sub-options

  • Encoding types are kept unchanged

    • ‘enc’ byte ‘0’  Domain name list

    • ‘enc’ byte ‘1’  IPv4 address list


Update of draft ietf mipshop mos dhcp options 041

Update of draft-ietf-mipshop-mos-dhcp-options-04

  • DHCPv6 has two Options

    • IPv6 MoS Identifier Option

    • IPv6 MoS information Option

  • MoS Information Option has several sub-options

  • Moved all Relay Agent options to Appendix

    • May be removed depending upon the outcome of the discussion of Integrated scenario


Update of draft ietf mipshop mos dns discovery 01

Update of draft-ietf-mipshop-mos-dns-discovery-01

  • Defines new application tags to discover MIH services (IS, CS, ES) accessible using certain transport protocols (e.g., UDP, TCP, SCTP)

  • Currently the draft says that new services and new transports may be registered with IANA on an FCFS basis


Comment 1

Comment # 1

  • Yoshihiro Ohba:

    • New transports may be registered on an FCFS basis, but new services should be defined by standards track RFCs

    • Clarify that messages belonging to ‘Service Management’ type are considered ES or CS types when L3 transport is used

  • The new version will incorporate the proposed changes


Comment 2

Comment # 2

  • Review received from Thomas Narten on 7/24

  • Comments mainly on the exceptions to the rule defined in the doc, some of them being added as a result of previous comments

  • The comments are going to be discussed on the mailing list and the draft will be updated accordingly

  • No additional comments were received


Draft stupar dime mos options

Draft-stupar-dime-mos-options

  • Addresses AAA extensions required for Integrated Scenario defined in the solution draft

  • Defines AVP extensions to convey Mobility Services information and its capability

  • ID presented in DIME, to be considered for DIME charter, if required by MIPSHOP


  • Login