From amuhanna@awardsolutions.com Sun Jun 2 12:21:31 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C00C21F9104 for ; Sun, 2 Jun 2013 12:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEXI3yMFNw3G for ; Sun, 2 Jun 2013 12:21:25 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by ietfa.amsl.com (Postfix) with ESMTP id AFF4421F919D for ; Sun, 2 Jun 2013 12:21:24 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKUaubM0n3nNyAr7iOY9EMXsp6TFJrf4o+@postini.com; Sun, 02 Jun 2013 12:21:25 PDT Received: from REDWOOD.usa.awardsolutions.com ([fe80::6d1b:ab4f:9248:e8a3]) by Redwood.usa.awardsolutions.com ([fe80::6d1b:ab4f:9248:e8a3%11]) with mapi id 14.01.0438.000; Sun, 2 Jun 2013 14:21:23 -0500 From: Ahmad Muhanna To: "netext@ietf.org" Thread-Topic: Review Comments on: draft-ietf-netext-pmip6-qos-02 Thread-Index: AQHOX8ZdB+OpDwjqFUavB5log0rF0w== Date: Sun, 2 Jun 2013 19:21:21 +0000 Message-ID: <3359F724933DFD458579D24EAC7690988B231081@Redwood.usa.awardsolutions.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.208.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Basavaraj Patil Subject: [netext] Review Comments on: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 19:21:31 -0000 Hi Raj and authors, I have reviewed this draft and I have the below comments. General Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have found it difficult to follow this document differentiation between I= P session, IP flows, Mobility Session with respect to QoS. Since this docum= ent reference 3GPP specification for the purpose of QoS, we realize that Qo= S (in 3GPP) is enforced at the level of a bearer. Thus, when we talk about = IP session, is that a single bearer or all types of traffic/flows is carrie= d over this IP session. May be the question is: what is the equivalent of a= bearer in PMIPv6? Then we should make sure that we use that definition whe= n referring to QoS enforcement. After reading on, section 4.1., mentions that the QoS is applied at three d= ifferent levels, IP flow, Mobility Session, or per MN. May be it is a good idea to have this mentioned upfront in the introduction= section in order to set the stage correctly. In addition somehow, this doc= ument needs to provide the detailed logic to differentiate between the thre= e cases.=20 Editorial: Comment No. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (a) Maintenance of QoS classification during a handover between cellular radio access and WLAN access by means of establishing QoS policies in the handover target access network, [Ahmad]=20 (a) Maintaining QoS classification .... Comment No. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This document specifies an extension to the PMIPv6 protocol, which enables the transport of established QoS descriptions between an LMA and the MAG by means of a QoS container option in case the QoS policy in the WLAN access is not under explicit control of a policy control system. [Ahmad] It is not clear what you are trying to say in here. I am thinking the autho= rs intention is to say that in case there is no out of bound policy control= mechanism, this document specifies an inbound mechanism using an extension= to the PMIPv6 protocol. May be this can be rephrased to capture the mentio= ned meaning. Comment No. 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The specified option allows association between IP session keys, such as a Differentiated Services Code Point (DSCP), and the expected QoS class for this IP session. [Ahmad] I have a problem with the word "keys", maybe we can say IP session classifi= cation parameters,=20 Comment No. 4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The MN is first connected to the LTE network and having a multimedia session such as a video call with appropriate QoS parameters set by the policy control function. [Ahmad] All of a sudden introduced LTE network, maybe we can rephrase this as follo= ws: The MN is first connected to the cellular network, e.g., LTE network, an= d having a multimedia ...... Comment No. 5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3.3. Use Case B -- Establishment of new QoS Context in non-3G Access [Ahmad] I guess the intention to say non-3GPP ? Comment No. 6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3.5. Relevant QoS Attributes [Ahmad] Although, TFT is not considered a QoS parameter, but it is quite important.= I did not see the UL TFT is mentioned anywhere. Is it handled outside this= document? If it is, we need to mention that because it tightly coupled wit= h the enforcement of the QoS. After reading on, there is Traffic Selector Attribute (section 4.1, etc). H= owever, the following text is a little misleading and gives the impression = as the additional attributes are out of scope. For some optional QoS attributes the signaling can differentiate enforcement per mobility session and per IP flow. Additional attributes can be appended to the QoS option, but their definition and specification is out of scope of this document and left to their actual deployment. I think the above text can be modified to clearly reference Traffic Selecto= r. Technical Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment No. 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 4.2 " Local Mobility Anchor Considerations" , it says the fol= lowing: The flow selectors and the parameters for flow treatment MUST be included in the option only if QoS policy is expected to apply at the flow level. On the other hand, under section 5, "Quality of Service Option", it says th= e DSCP value to be used for the flow: o DSCP: An 6-bit unsigned integer indicating the code point value, as defined in [RFC2475] to be used for the flow. [Ahmad] It is not clear to me how this will work out. If the DSCP is a fixed field = in the QoS option, then how this will work to allow having different flows = with different DSCP(s). Let me try to explain where I am lost! :-) If the mobility session was established for default kind of traffic and the= QoS DSCP was communicated for a QCI of 9 (DSCP1) for example. Then at a la= ter time, the MN establishes some application session (flow) with QCI 1 and= the returned QoS has a DSCP (DSCP2) in the fixed field and probably a Traf= fic Selector since it is a per single flow. Now: when the MAG receives the new PBA, is DSCP2 for this flow only and the= old DSCP1 for every other traffic? How that should work in relation with t= he above DSCP field definition? Comment No. 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 6, the Guaranteed Downlink Bit Rate is missing. Comment No. 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Under section 6.8, "Traffic Selector", it says the following: MUST be included if QoS parameters (Options according to Section 6.5 to Section 6.7) are expected to apply at the flow level [Ahmad] Why did you single out these two sections only? For example, section 6.5, says the following: " 6.5. Allocation and Retention Priority ....... If the attribute is expected to apply at the flow level, the traffic selector (Section 6.8) MUST be included in the QoS option. " I suggest modifying the text as follows: =20 MUST be included when QoS is expected to be applied at the flow level. Comment No. 4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since the Guaranteed Downlink Bit Rate is missing, please recheck the assig= ned type values and their order in section 6 and the following subsections.= Also, please update the IANA section accordingly. Regards, Ahmad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++ From: Basavaraj Patil [mailto:bpatil1@gmail.com]=20 Sent: Tuesday, May 14, 2013 4:37 PM To: Ahmad Muhanna Cc: netext@ietf.org Subject: Request for review of I-D: draft-ietf-netext-pmip6-qos-02 Hi Ahmad, We would appreciate it if you can review the I-D:=A0uality of Service Optio= n for Proxy Mobile IPv6 . Please post your review comments directly to the list. If you can complete = the review within the next 2 weeks, that would be much appreciated. Thank you. -Chairs --=20 Basavaraj Patil=20 From yokota@kddilabs.jp Thu Jun 6 23:40:04 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E124721F90FD for ; Thu, 6 Jun 2013 23:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_33=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK8vdPHCjwkO for ; Thu, 6 Jun 2013 23:40:03 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id A073521F90EF for ; Thu, 6 Jun 2013 23:40:02 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id B39971748111 for ; Fri, 7 Jun 2013 15:40:01 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS3Rd4wmQF0U for ; Fri, 7 Jun 2013 15:40:00 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8E6C017480E5 for ; Fri, 7 Jun 2013 15:40:00 +0900 (JST) Received: from [127.0.0.1] (dhcp250.west-4f.cn.kddilabs.jp [172.19.124.250]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id A1A1D1B9B7 for ; Fri, 7 Jun 2013 15:33:01 +0900 (JST) Message-ID: <51B1803F.8040500@kddilabs.jp> Date: Fri, 07 Jun 2013 15:39:59 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "netext@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070501000405060207040604" Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:40:05 -0000 This is a multi-part message in MIME format. --------------070501000405060207040604 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Raj, Sincere apology for our delayed response. Thanks a lot for your thorough review and comments. Please see inline for our response (we have one question about your comment #7). We will update the I-D and submit as soon as possible. (2013/05/14 4:19), Basavaraj Patil wrote: > > Below are my review comments for the > I-D:draft-ietf-netext-pmip6-qos-02 (QoS Support for Proxy Mobile IPv6) > > > Questions/Comments: > > 1. "Using the QoS option, the local mobility anchor and the > mobile access gateway can exchange available QoS attributes and > associated values." > > QoS for a session or subscriber or group of sessions? Not clear from > this statement. > *That depends on the type of QoS attribute. As shown in Section 6 (below Fig.7), Type=1 is Per-mobile node (could be a group of sessions), whereas Type=3 is per-session.* > 2. "This enables QoS policing and labeling of packets > to enforce QoS differentiation on the path between the local mobility > anchor and the mobile access gateway." > > So is the objective primarily to enable QoS on the MAG<->LMA path? Or > is the intent to deliver QoS information to the MAG for use on the > access link? Or both? > *For both the path between MAG and LMA and access link. Figs. 4 and 5 illustrate how QoS parameters are delivered and set.* > 3. "Furthermore, making QoS > parameters available on the MAG enables mapping these parameters to > QoS rules being specific to the access technology which operates > below the mobile access gateway." > > Would this mapping be defined elsewhere? As an example how would you > translate the QoS parameters defined between the MAG<->LMA for use on > an 802.11 air interface? Who would define this mapping (if it needs to > be specified). > *Appendix A shows an example of how QoS parameters are mapped to IEEE802.11e.* > 4. "Current > standardization effort considers strong QoS classification and > enforcement for cellular radio access technologies." > > What standardization effort is being referred to here? > *3GPP is one of those and Section 3.5 shows detailed parameters. * > 5. "QoS policies are > typically controlled by a policy control function, ...." > > The I-D assumes a very specific network architecture (in this case > 3GPP EPS). It would be better to indicate the applicability or > assumptions. > *This sentence can go without the description of "policy control function".* > 6. "Policy control and QoS differentiation for access to the mobile > operator network through alternative non-cellular access technologies > is not yet considered, even though some of these access technologies > are able to support QoS by appropriate traffic prioritization > techniques." > > Not sure how this is relevant in the scope of this I-D. > *This part can be removed.* > 7. "... alternative > radio access technologies, such as IEEE802.16 " > > Would be good to include EV-DO, SCDMA as other technologies as well... > *EV-DO could be another example standardized by 3GPP2, but could you tell us which SDO standardized SCDMA?* > 8. " whereas inter-working with the cellular > architecture to establish QoS policies in alternative access networks > has not been focussed on so far." > > The WG is better off defining a mechanism that is not specific to the > current version of 3GPP standards or access technologies being > considered. > *The defined mechanism is not only for 3GPP, but also for WiFi as shown in Appendix A or for broadband fixed network as shown in Appendix B. * > 9. "...has been identified as > promising alternative technology to complement cellular radio > access." > > It already complements cellular access.. Why is it considered > promising? > *"promising" should be removed.* > 10. " This specification > does not depend on the approach how the cellular specific QoS > policies have been configured on the LMA. " > > Is there not a need to have QoS for flows between a MAG and LMA given > that an MN may have multiple flows between a MAG<->LMA pair? > *The QoS for multiple flows between MAG and LMA is also possible. Traffic selector defined in Secion 6.8 identifies each flow for assigning a separate QoS.* > 11. "The MN is first connected to the LTE network and having a multimedia > session such as a video call with appropriate QoS parameters set by > the policy control function. " > > What QoS policies are configured at the MAG/LMA for such a flow by the > PCF? And how are these applied? > *In the case of video call, QCI=2 is used as per 3GPP's definition and the PCF delivers necessary parameters to the LMA accordingly. * > 12. "The MN is first attaching to > the Wi-Fi network. During attachment process, the LMA, which may be > in communication with Policy Control Function (this step of the > process is out of the scope of this document), provides the QoS > parameters to the MAG piggy-backing the PMIP signaling (i.e. > PBA)." > > Several assumptions being made here. It could also be the case that > when the MN attaches to a WiFI AP which has QoS support, it could > request specific QoS already for a session. That is not considered > here. > *Local QoS policy assignment does not require QoS parameters from the LMA, but can be included as a possible use case in the document.* > 13. Sec 3.5 describes QCI, ARP, AMBR, GBR etc. which are all 3GPP > specific for QoS. It is not clear how these are incorporated into the > signaling between PMIP6 nodes and how they are mapped/applied. > > 3GPP has specified all these QoS types. If the PMIP6 elements, > MAG/LMA, do not support QoS signaling does it imply that 3GPP networks > will be unable to use QoS if PMIP6 is used as the mobility protocol? > *In such a case, another mechanism is used in 3GPP. Instead of PMIPv6 signaling, a dedicated interface called Gxx is defined between the policy server and MAG. Of course, this is not an ideal situation and this I-D will fix it.* > 14. The I-D specifies various QoS options defined in 3GPP such as > AMBR, GBR, etc. in sections 6.x. 3GPP may continue to expand or > deprecate these options. Why not simply follow the 3GPP defined QoS > parameters and allocate a generic 3GPP option instead of assigning a > type value to each one of these by IANA? > *3GPP-defined QoS parameters have been stable enough and referred to by other SDOs as well. These parameters can be separately used by other access technologies, so it would be more convenient to define each than put into a 3GPP option, which would be invisible other than 3GPP.* > 15. The I-D makes assumptions about interacting with a policy > controller for obtaining the QoS parameters. What happens in the > absence of such a PCF element? Can the LMA itself be configured to > allocate QoS to a session? > *LMA-based predefined policy control is also possible. In this case, static policy will be applied by the LMA.* > 16. And lastly why not simply specify DSCP and the QoS for the traffic > between the MAG and LMA instead of worrying about the mapping to > access technology types and interaction with different elements in the > access. > *We are not worried about other access technologies, but just trying to show multiple use cases for the applicability of this specification.* Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp > -Raj > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --------------070501000405060207040604 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Raj,

Sincere apology for our delayed response.

Thanks a lot for your thorough review and comments. Please see inline for our response (we have one question about your comment #7). We will update the I-D and submit as soon as possible.

(2013/05/14 4:19), Basavaraj Patil wrote:

Below are my review comments for the I-D:draft-ietf-netext-pmip6-qos-02 (QoS Support for Proxy Mobile IPv6)


Questions/Comments:

1. "Using the QoS option, the local mobility anchor and the
   mobile access gateway can exchange available QoS attributes and
   associated values."

QoS for a session or subscriber or group of sessions? Not clear from
this statement.


That depends on the type of QoS attribute. As shown in Section 6 (below Fig.7), Type=1 is Per-mobile node (could be a group of sessions), whereas Type=3 is per-session.

2. "This enables QoS policing and labeling of packets
   to enforce QoS differentiation on the path between the local mobility
   anchor and the mobile access gateway."

So is the objective primarily to enable QoS on the MAG<->LMA path? Or
is the intent to deliver QoS information to the MAG for use on the
access link? Or both?


For both the path between MAG and LMA and access link. Figs. 4 and 5 illustrate how QoS parameters are delivered and set.

3. "Furthermore, making QoS
   parameters available on the MAG enables mapping these parameters to
   QoS rules being specific to the access technology which operates
   below the mobile access gateway."

Would this mapping be defined elsewhere? As an example how would you
translate the QoS parameters defined between the MAG<->LMA for use on
an 802.11 air interface? Who would define this mapping (if it needs to
be specified).


Appendix A shows an example of how QoS parameters are mapped to IEEE802.11e.

4. "Current
   standardization effort considers strong QoS classification and
   enforcement for cellular radio access technologies."

What standardization effort is being referred to here? 


3GPP is one of those and Section 3.5 shows detailed parameters.

5. "QoS policies are
   typically controlled by a policy control function, ...."

The I-D assumes a very specific network architecture (in this case
3GPP EPS). It would be better to indicate the applicability or
assumptions. 


This sentence can go without the description of "policy control function".

6. "Policy control and QoS differentiation for access to the mobile
   operator network through alternative non-cellular access technologies
   is not yet considered, even though some of these access technologies
   are able to support QoS by appropriate traffic prioritization
   techniques."

Not sure how this is relevant in the scope of this I-D.


This part can be removed.

7. "... alternative
   radio access technologies, such as IEEE802.16 "

Would be good to include EV-DO, SCDMA as other technologies as well...


EV-DO could be another example standardized by 3GPP2, but could you tell us which SDO standardized SCDMA?

8. " whereas inter-working with the cellular
   architecture to establish QoS policies in alternative access networks
   has not been focussed on so far."

The WG is better off defining a mechanism that is not specific to the
current version of 3GPP standards or access technologies being
considered.


The defined mechanism is not only for 3GPP, but also for WiFi as shown in Appendix A or for broadband fixed network as shown in Appendix B.

9. "...has been identified as
   promising alternative technology to complement cellular radio
   access."

It already complements cellular access.. Why is it considered
promising?


"promising" should be removed.

10. " This specification
   does not depend on the approach how the cellular specific QoS
   policies have been configured on the LMA. "

Is there not a need to have QoS for flows between a MAG and LMA given
that an MN may have multiple flows between a MAG<->LMA pair?


The QoS for multiple flows between MAG and LMA is also possible. Traffic selector defined in Secion 6.8 identifies each flow for assigning a separate QoS.

11. "The MN is first connected to the LTE network and having a multimedia
   session such as a video call with appropriate QoS parameters set by
   the policy control function. "

What QoS policies are configured at the MAG/LMA for such a flow by the
PCF? And how are these applied?


In the case of video call, QCI=2 is used as per 3GPP's definition and the PCF delivers necessary parameters to the LMA accordingly.

12. "The MN is first attaching to
   the Wi-Fi network.  During attachment process, the LMA, which may be
   in communication with Policy Control Function (this step of the
   process is out of the scope of this document), provides the QoS
   parameters to the MAG piggy-backing the PMIP signaling (i.e.
   PBA)."

Several assumptions being made here. It could also be the case that
when the MN attaches to a WiFI AP which has QoS support, it could
request specific QoS already for a session. That is not considered
here.


Local QoS policy assignment does not require QoS parameters from the LMA, but can be included as a possible use case in the document.

13. Sec 3.5 describes QCI, ARP, AMBR, GBR etc. which are all 3GPP
specific for QoS. It is not clear how these are incorporated into the
signaling between PMIP6 nodes and how they are mapped/applied.

3GPP has specified all these QoS types. If the PMIP6 elements,
MAG/LMA, do not support QoS signaling does it imply that 3GPP networks
will be unable to use QoS if PMIP6 is used as the mobility protocol?


In such a case, another mechanism is used in 3GPP. Instead of PMIPv6 signaling, a dedicated interface called Gxx is defined between the policy server and MAG. Of course, this is not an ideal situation and this I-D will fix it.

14. The I-D specifies various QoS options defined in 3GPP such as
AMBR, GBR, etc. in sections 6.x. 3GPP may continue to expand or
deprecate these options. Why not simply follow the 3GPP defined QoS
parameters and allocate a generic 3GPP option instead of assigning a
type value to each one of these by IANA?


3GPP-defined QoS parameters have been stable enough and referred to by other SDOs as well. These parameters can be separately used by other access technologies, so it would be more convenient to define each than put into a 3GPP option, which would be invisible other than 3GPP.

15. The I-D makes assumptions about interacting with a policy
controller for obtaining the QoS parameters. What happens in the
absence of such a PCF element? Can the LMA itself be configured to
allocate QoS to a session?


LMA-based predefined policy control is also possible. In this case, static policy will be applied by the LMA.

16. And lastly why not simply specify DSCP and the QoS for the traffic
between the MAG and LMA instead of worrying about the mapping to
access technology types and interaction with different elements in the
access.


We are not worried about other access technologies, but just trying to show multiple use cases for the applicability of this specification.

Regards,
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp


-Raj




_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext

--------------070501000405060207040604-- From sgundave@cisco.com Mon Jun 10 05:49:13 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965DD21F85E6 for ; Mon, 10 Jun 2013 05:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNeYxYcvl7ru for ; Mon, 10 Jun 2013 05:49:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 650BF21F87E1 for ; Mon, 10 Jun 2013 05:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=91965; q=dns/txt; s=iport; t=1370868468; x=1372078068; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=YRerUYcSPF0RGNQCxHkjGfRV+dtAi2+pWQDhprPjNOA=; b=Lhgid83r1MrsX7PoZPBK3c4y69hY3l27D0gKsHI9JHM89E9zhMTawGNq wpu2PnzRq+p3UVHS7BYnD7mjKI/sLtEdYvD6upQJKqnAo8x80WUraYKc4 9SEGTqDrraschWBlPg/tG3dVvkeCT2ijlOIUYxkCpsLgebNko3weeroTY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYFAF7KtVGtJXG8/2dsb2JhbABagkVEeYIaWrtNDXYWbQeCIwEBAQMBDA4DEDoECQMHDQEGAhEDAQEBCxYBBgUEHxEUBwEBBQMBAQQTCBKHYQMJBow6jEOObg6IMQ2IUoxbgRqBEgYHExcBBAKCPTxhA5VZjgWFJIMPgWgHOA X-IronPort-AV: E=Sophos;i="4.87,836,1363132800"; d="scan'208,217";a="220862929" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jun 2013 12:47:47 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5AClkQh000325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Jun 2013 12:47:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.104]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 07:47:46 -0500 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: End Marker enhancements for PMIP Update Notification Thread-Index: Ac5lkw5xt/RzgTbmSKGi2KY7qRdDgP//+FEAgAB4SAD//6C+AIAAgOeA///Xg4A= Date: Mon, 10 Jun 2013 12:47:45 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8102D83EF@xmb-aln-x03.cisco.com> In-Reply-To: <04ba01ce65b2$44f14650$ced3d2f0$@nttdocomo.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.214] Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA8102D83EFxmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [netext] FW: End Marker enhancements for PMIP Update Notification X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 12:49:14 -0000 --_000_24C0F3E22276D9438D6F366EB89FAEA8102D83EFxmbalnx03ciscoc_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 RllJLiBEaXNjdXNzaW9uIHdpdGggM0dQUCBTQTIvQ1Q0IG1lbWJlcnMgb24gYWRkaW5nIGEgbmV3 IHN0YXR1cyBjb2RlIHZhbHVlIHRvIHRoZSBVcGRhdGUgTm90aWZpY2F0aW9uIGRyYWZ0Lg0KDQpU aGlzIGRyYWZ0IGhhcyBqdXN0IGZpbmlzaGVkIFdHIExDIGNhbGwsIGJ1dCB3ZSBwbGFuIHRvIG1h a2UgdGhpcyBjaGFuZ2UgKGFkZGluZyBhIFJlYXNvbiBDb2RlKSBhbmQga2VlcCB0aGUgc2VtYW50 aWNzIGNsZWFuLg0KDQpDb21tZW50cyB3ZWxjb21lLg0KDQpSZWdhcmRzDQpTcmkNCg0KDQoNCg0K DQpGcm9tOiBJdHN1bWEgVEFOQUtBIDx0YW5ha2FpQG50dGRvY29tby5jby5qcDxtYWlsdG86dGFu YWthaUBudHRkb2NvbW8uY28uanA+Pg0KRGF0ZTogTW9uZGF5LCBKdW5lIDEwLCAyMDEzIDE6MTIg QU0NClRvOiBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpzZ3VuZGF2 ZUBjaXNjby5jb20+PiwgInpob3UueGluZ3l1ZUBaVEUuQ09NLkNOPG1haWx0bzp6aG91Lnhpbmd5 dWVAWlRFLkNPTS5DTj4iIDx6aG91Lnhpbmd5dWVAWlRFLkNPTS5DTjxtYWlsdG86emhvdS54aW5n eXVlQFpURS5DT00uQ04+PiwgIidCRVJSWSwgTmlnZWwgKE5pZ2VsKSciIDxuaWdlbC5iZXJyeUBB TENBVEVMLUxVQ0VOVC5DT008bWFpbHRvOm5pZ2VsLmJlcnJ5QEFMQ0FURUwtTFVDRU5ULkNPTT4+ LCAiJ1dpbGQsIFBldGVyIEFsZXhhbmRlciwgVm9kYWZvbmUgREUnIiA8cGV0ZXIud2lsZEB2b2Rh Zm9uZS5jb208bWFpbHRvOnBldGVyLndpbGRAdm9kYWZvbmUuY29tPj4sICdGcmFuayBZb25nIFlh bmcnIDxmcmFuay55b25nLnlhbmdARVJJQ1NTT04uQ09NPG1haWx0bzpmcmFuay55b25nLnlhbmdA RVJJQ1NTT04uQ09NPj4sICInU2hpc2h1ZmVuZyAoU3VzYW4pJyIgPHN1c2FuLnNoaXNodWZlbmdA SFVBV0VJLkNPTTxtYWlsdG86c3VzYW4uc2hpc2h1ZmVuZ0BIVUFXRUkuQ09NPj4sICdTaGFoYWIg TGF2YXNhbmknIDxzaGFoYWIubGF2YXNhbmlASFVBV0VJLkNPTTxtYWlsdG86c2hhaGFiLmxhdmFz YW5pQEhVQVdFSS5DT00+PiwgIidNaWx0b24sIExldyAoTlNOIC0gVVMvQXJsaW5ndG9uIEhlaWdo dHMpJyIgPGxldy5taWx0b25ATlNOLkNPTTxtYWlsdG86bGV3Lm1pbHRvbkBOU04uQ09NPj4sICIn TEFOREFJUywgQlJVTk8gKEJSVU5PKSciIDxicnVuby5sYW5kYWlzQGFsY2F0ZWwtbHVjZW50LmNv bTxtYWlsdG86YnJ1bm8ubGFuZGFpc0BhbGNhdGVsLWx1Y2VudC5jb20+PiwgImtvamkud2F0YW5h YmUuYXpAaGl0YWNoaS5jb208bWFpbHRvOmtvamkud2F0YW5hYmUuYXpAaGl0YWNoaS5jb20+IiA8 a29qaS53YXRhbmFiZS5hekBoaXRhY2hpLmNvbTxtYWlsdG86a29qaS53YXRhbmFiZS5hekBoaXRh Y2hpLmNvbT4+LCAidGFtdXJhdG9AYWouanAubmVjLmNvbTxtYWlsdG86dGFtdXJhdG9AYWouanAu bmVjLmNvbT4iIDx0YW11cmF0b0Bhai5qcC5uZWMuY29tPG1haWx0bzp0YW11cmF0b0Bhai5qcC5u ZWMuY29tPj4sICJqYW4ua2FsbEBuc24uY29tPG1haWx0bzpqYW4ua2FsbEBuc24uY29tPiIgPGph bi5rYWxsQG5zbi5jb208bWFpbHRvOmphbi5rYWxsQG5zbi5jb20+PiwgIk5pcmF2IFNhbG90IChu c2Fsb3QpIiA8bnNhbG90QGNpc2NvLmNvbTxtYWlsdG86bnNhbG90QGNpc2NvLmNvbT4+LCAnUmFo dWwgU3VoYXMgVmFpZHlhJyA8cmFodWx2QGp1bmlwZXIubmV0PG1haWx0bzpyYWh1bHZAanVuaXBl ci5uZXQ+PiwgImpsYWdhbmllckBqdW5pcGVyLm5ldDxtYWlsdG86amxhZ2FuaWVyQGp1bmlwZXIu bmV0PiIgPGpsYWdhbmllckBqdW5pcGVyLm5ldDxtYWlsdG86amxhZ2FuaWVyQGp1bmlwZXIubmV0 Pj4sICdKZXN1cyBEZSBHcmVnb3JpbycgPGplc3VzLmRlLmdyZWdvcmlvQEVSSUNTU09OLkNPTTxt YWlsdG86amVzdXMuZGUuZ3JlZ29yaW9ARVJJQ1NTT04uQ09NPj4sICdQZXRlciBTY2htaXR0JyA8 UGV0ZXIuU2NobWl0dEBIVUFXRUkuQ09NPG1haWx0bzpQZXRlci5TY2htaXR0QEhVQVdFSS5DT00+ PiwgJ0hpZGV0b3NoaSBZb2tvdGEnIDx5b2tvdGFAa2RkaWxhYnMuanA8bWFpbHRvOnlva290YUBr ZGRpbGFicy5qcD4+LCAiam91bmkubm9zcGFtQGdtYWlsLmNvbTxtYWlsdG86am91bmkubm9zcGFt QGdtYWlsLmNvbT4iIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPG1haWx0bzpqb3VuaS5ub3NwYW1A Z21haWwuY29tPj4sICJtYXJjby5saWVic2NoQG53Lm5lY2xhYi5ldTxtYWlsdG86bWFyY28ubGll YnNjaEBudy5uZWNsYWIuZXU+IiA8bWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU8bWFpbHRvOm1h cmNvLmxpZWJzY2hAbncubmVjbGFiLmV1Pj4sICJzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29t PG1haWx0bzpzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPiIgPHN1cmVzaC5rcmlzaG5hbkBl cmljc3Nvbi5jb208bWFpbHRvOnN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+PiwgIkJhc2F2 YXJhaiBQYXRpbCAoYmFzYXZwYXQpIiA8YmFzYXZwYXRAY2lzY28uY29tPG1haWx0bzpiYXNhdnBh dEBjaXNjby5jb20+Pg0KQ2M6ICJuaXNoaWRha0BudHRkb2NvbW8uY28uanA8bWFpbHRvOm5pc2hp ZGFrQG50dGRvY29tby5jby5qcD4iIDxuaXNoaWRha0BudHRkb2NvbW8uY28uanA8bWFpbHRvOm5p c2hpZGFrQG50dGRvY29tby5jby5qcD4+LCAic2hpbi55b2tveWFtYS5rY0BzMS5udHRkb2NvbW8u Y29tPG1haWx0bzpzaGluLnlva295YW1hLmtjQHMxLm50dGRvY29tby5jb20+IiA8c2hpbi55b2tv eWFtYS5rY0BzMS5udHRkb2NvbW8uY29tPG1haWx0bzpzaGluLnlva295YW1hLmtjQHMxLm50dGRv Y29tby5jb20+PiwgJ0F0c3VzaGkgTWlub2t1Y2hpJyA8bWlub2t1Y2hpQG50dGRvY29tby5jby5q cDxtYWlsdG86bWlub2t1Y2hpQG50dGRvY29tby5jby5qcD4+LCAnWmhlbiBNaWFvJyA8bWlhb0Bu dHRkb2NvbW8uY28uanA8bWFpbHRvOm1pYW9AbnR0ZG9jb21vLmNvLmpwPj4NClN1YmplY3Q6IFJF OiBFbmQgTWFya2VyIGVuaGFuY2VtZW50cyBmb3IgUE1JUCBVcGRhdGUgTm90aWZpY2F0aW9uDQoN CkRlYXIgU3JpLCBhbGwsDQoNCk1hbnkgdGhhbmtzoUsNCkZpcnN0IG9mIGFsbCB3ZaGmcmUgTk9U IHRoaW5raW5nIGFib3V0IGludHJvZHVjaW5nIGEgbmV3IFJlYXNvbiB2YWx1ZSBzcGVjaWZpYyB0 byChp2VuZCBtYXJrZXKhqC4NCkFuZCB3ZaGmcmUgb2sgdG8gcmUtdXNlIHRoZSBleGlzdGluZyBS ZWFzb24gdmFsdWUgKGkuZS4goadVUERBVEUtU0VTU0lPTi1QQVJBTUVURVJToagpIGlmIGV2ZXJ5 Ym9keSBpcyBoYXBweSB3aXRoIGl0Lg0KQW5kIEkgYWxzbyBmdWxseSBhZ3JlZSB3aXRoIHlvdXIg c3RhdGVtZW50IHRoYXQgoad0aGUgb3B0aW9uL3VzZS1jYXNlIHNob3VsZCBiZSBicm9hZGx5IGFw cGxpY2FibGUgYmV5b25kIDNHUFAgc3lzdGVtoagNCg0KPmlmIHRoaXMgZG9lcyBub3Qgc291bmQg bGlrZSBhIGNsZWFuIGFwcHJvYWNoLCB3ZSBjYW4gY2VydGFpbmx5IGRlZmluZSBhIG5ldyBTdGF0 dXMgQ29kZSwgd2hpY2ggaXMgIlZlbmRvci1TcGVjaWZpYyBSZWFzb24gKDMpIi4gICBUaGUgcGVl ciBjYW4gaGFuZGxlIHRoZSBVUE4gbWVzc2FnZSBiYXNlZCBvbiB0aGF0IHZlbmRvci1zcGVjaWZp YyBvcHRpb24uIElzIHRoaXMgd2hhdCB5b3UgYXJlIHRoaW5raW5nID8NCg0KQnV0IGFjdHVhbGx5 IEkgbGlrZSB5b3VyIGlkZWEgb2YgYWRkaW5nIGEgZ2VuZXJpYyBuZXcgdmFsdWUgKKGnVmVuZG9y LVNwZWNpZmljIFJlYXNvbiAoMymhqCksIGJlY2F1c2UgSSBzZW5zZSB0aGVyZaGmcyBhIHBvc3Np YmlsaXR5IHRoYXQ6DQoNCjEuICAgICAgQ1Q0IGFyZ3VlcyByZS11c2luZyBleGlzdGluZyBvbmUg aXMgbm90IGNsZWFuDQoNCjIuICAgICBUaGVyZSBtYXkgYmUgbmV3IGVuaGFuY2VtZW50cyBpbiB0 aGUgZnV0dXJlIHdoaWNoIG1pZ2h0IHJlcXVpcmUgYWRkaXRpb24gb2YgbmV3IGNhdXNlIHZhbHVl DQpTbyBpZiB3ZSBjb3VsZCBoYXZlIHNvbWV0aGluZyBnZW5lcmljIGluIHRoZSBJLUQsIEkgdGhp bmsgdGhpcyBtYWtlcyBpdCBwcmV0dHkgbXVjaCBmdXR1cmUgcHJvb2YuDQpJZiB3ZSBjb3VsZCBk byB0aGF0IGFkZGl0aW9uIG5vdywgdGhlbiBJIHRoaW5rIGl0oaZzIGFsc28gZ29vZCBmcm9tIElF VEYgcHJvY2VkdXJlIHBvaW50IG9mIHZpZXcgKEkgbWVhbiBsZXNzIGRlbGF5IGluIHRoZSBwcm9j ZXNzoUthcyB3ZSBkb26hpnQgbmVlZCB0byB3YWl0IGZvciBDVDQgZGlzY3Vzc2lvbikNCg0KV2hh dCBkbyB5b3UgdGhpbms/IEmhpmQgbGlrZSB0byBhbHNvIGludml0ZSBjb21tZW50cyBmcm9tIG90 aGVyIGNvbXBhbmllc6FLDQoNClJlZ2FyZHMsDQpJdHN1bWENCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkl0c3VtYSBUQU5BS0EgKKXQ pKSrwqx6sKgpDQpHU01BIElSRUcgVmljZSBDaGFpciAvIElSRUcgUGFja2V0IENoYWlyDQoNCk5U VCBET0NPTU8sIEluYy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCg0KRnJvbTogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSBbbWFp bHRvOnNndW5kYXZlQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAxMCwgMjAxMyA0OjMx IFBNDQpUbzogSXRzdW1hIFRBTkFLQTsgemhvdS54aW5neXVlQFpURS5DT00uQ048bWFpbHRvOnpo b3UueGluZ3l1ZUBaVEUuQ09NLkNOPjsgJ0JFUlJZLCBOaWdlbCAoTmlnZWwpJzsgJ1dpbGQsIFBl dGVyIEFsZXhhbmRlciwgVm9kYWZvbmUgREUnOyAnRnJhbmsgWW9uZyBZYW5nJzsgJ1NoaXNodWZl bmcgKFN1c2FuKSc7ICdTaGFoYWIgTGF2YXNhbmknOyAnTWlsdG9uLCBMZXcgKE5TTiAtIFVTL0Fy bGluZ3RvbiBIZWlnaHRzKSc7ICdMQU5EQUlTLCBCUlVOTyAoQlJVTk8pJzsga29qaS53YXRhbmFi ZS5hekBoaXRhY2hpLmNvbTxtYWlsdG86a29qaS53YXRhbmFiZS5hekBoaXRhY2hpLmNvbT47IHRh bXVyYXRvQGFqLmpwLm5lYy5jb208bWFpbHRvOnRhbXVyYXRvQGFqLmpwLm5lYy5jb20+OyBqYW4u a2FsbEBuc24uY29tPG1haWx0bzpqYW4ua2FsbEBuc24uY29tPjsgTmlyYXYgU2Fsb3QgKG5zYWxv dCk7ICdSYWh1bCBTdWhhcyBWYWlkeWEnOyBqbGFnYW5pZXJAanVuaXBlci5uZXQ8bWFpbHRvOmps YWdhbmllckBqdW5pcGVyLm5ldD47ICdKZXN1cyBEZSBHcmVnb3Jpbyc7ICdQZXRlciBTY2htaXR0 JzsgJ0hpZGV0b3NoaSBZb2tvdGEnOyBqb3VuaS5ub3NwYW1AZ21haWwuY29tPG1haWx0bzpqb3Vu aS5ub3NwYW1AZ21haWwuY29tPjsgbWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU8bWFpbHRvOm1h cmNvLmxpZWJzY2hAbncubmVjbGFiLmV1Pjsgc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTxt YWlsdG86c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT47IEJhc2F2YXJhaiBQYXRpbCAoYmFz YXZwYXQpDQpDYzogbmlzaGlkYWtAbnR0ZG9jb21vLmNvLmpwPG1haWx0bzpuaXNoaWRha0BudHRk b2NvbW8uY28uanA+OyBzaGluLnlva295YW1hLmtjQHMxLm50dGRvY29tby5jb208bWFpbHRvOnNo aW4ueW9rb3lhbWEua2NAczEubnR0ZG9jb21vLmNvbT47ICdBdHN1c2hpIE1pbm9rdWNoaSc7ICda aGVuIE1pYW8nDQpTdWJqZWN0OiBSZTogRW5kIE1hcmtlciBlbmhhbmNlbWVudHMgZm9yIFBNSVAg VXBkYXRlIE5vdGlmaWNhdGlvbg0KDQpIaSBJdHN1bWEtc2FuLA0KDQpUaGFua3MgZm9yIHlvdXIg cmVzcG9uc2UuDQoNCj4gU28gaXMgaXQgY29ycmVjdCB1bmRlcnN0YW5kaW5nIHRoYXQgM0dQUCBj YW4gZGVmaW5lIHRoZWlyIG93biChp05vdGlmaWNhdGlvbiBSZWFzb26hqD8NCg0KV2Ugd2VyZSBu b3QgdGhpbmtpbmcgb2YgZGVmaW5pbmcgYSBSZWFzb24gQ29kZSBmb3IgdGhpcyBvdXRzaWRlIHRo ZSBWZW5kb3ItU3BlY2lmaWMgb3B0aW9uLg0KDQpUaGUgUmVhc29uIENvZGUgaW4gdGhlIFVQTiBt ZXNzYWdlIHdoZW4gdGhpcyBWZW5kb3Itc3BlY2lmaWMgb3B0aW9uIGlzIGluY2x1ZGVkIGNhbiBi ZSAiVVBEQVRFLVNFU1NJT04tUEFSQU1FVEVSUyIsIHdoaWNoIGRvZXMgbm90IHJlcXVpcmUgdGhl IHBlZXIgdG8gc2VuZCBhIG5ldyBQQlUsIGJ1dCBpbnN0ZWFkIHJlcXVpcmVzIGl0IHRvIHVwZGF0 ZSB0aGUgc2Vzc2lvbiBzdGF0ZS4gVGhhdCB1cGRhdGUgYW5kIHRoZSBhc3NvY2lhdGVkIGFjdGlv biBpcyB3aGF0IHRoZSBWZW5kb3ItU3BlY2lmaWMgb3B0aW9uIGRlZmluZXMgKHdoZW4gcHJlc2Vu dCkuDQoNClRoZSBwcmVzZW5jZSBvZiB0aGUgVmVuZG9yLVNwZWNpZmljIG9wdGlvbiBoaW50cyB0 aGUgcGVlciB0byBjb25mb3JtIHRvIGEgc3BlY2lmaWMgYmVoYXZpb3IgYW5kIHRoYXQgYmVoYXZp b3IgaXMgd2hhdCBDVDQgZGVmaW5lcy4gSWYgdGhlcmUgYXJlIG11bHRpcGxlIEFjdGlvbnMgYXNz b2NpYXRlZCB3aXRoIHRoaXMgVmVuZG9yLXNwZWNpZmljIG9wdGlvbiwgdGhlIG9wdGlvbiBpdHNl bGYgY2FuIGRlZmluZSBhIHZlbmRvciBzcGVjaWZpYyBBY3Rpb24vUmVhc29uIENvZGUuDQoNCkJ1 dCwgaWYgdGhpcyBkb2VzIG5vdCBzb3VuZCBsaWtlIGEgY2xlYW4gYXBwcm9hY2gsIHdlIGNhbiBj ZXJ0YWlubHkgZGVmaW5lIGEgbmV3IFN0YXR1cyBDb2RlLCB3aGljaCBpcyAiVmVuZG9yLVNwZWNp ZmljIFJlYXNvbiAoMykiLiAgIFRoZSBwZWVyIGNhbiBoYW5kbGUgdGhlIFVQTiBtZXNzYWdlIGJh c2VkIG9uIHRoYXQgdmVuZG9yLXNwZWNpZmljIG9wdGlvbi4gSXMgdGhpcyB3aGF0IHlvdSBhcmUg dGhpbmtpbmcgPw0KDQpCdXQsIGlmIHRoZSBSZWFzb24gQ29kZSBuZWVkcyB0byBoaW50IHNwZWNp ZmljYWxseSB0byAiRW5kIE1hcmtlciIgdXNlLWNhc2UsIHRoZW4gSU1PLCB0aGUgb3B0aW9uL3Vz ZS1jYXNlIHNob3VsZCBiZSBicm9hZGx5IGFwcGxpY2FibGUgYmV5b25kIDNHUFAgc3lzdGVtLiBF YXNpZXIgYXBwcm9hY2ggaXMgdG8gY29udGFpbiB0aGUgdXNlY2FzZS9iZWhhdmlvci9hY3Rpb24g dG8gdGhlIHZlbmRvci1zcGVjaWZpYyBvcHRpb24gYW5kIGtlZXAgdGhpcyB0byAzR1BQLg0KDQoN Cj4gVGhlIG5leHQgM0dQUCBDVDQgbWVldGluZyB3aWxsIGJlIGluIEF1Z3VzdCAyMDEzIKFWIHNv IGlzbqGmdCBpdCBhIGJpdCB0b28gbGF0ZSB3aGVuIHNvbWUgY2hhbmdlcy9jbGFyaWZpY2F0aW9u IGFyZSBuZWVkZWQgaW4gSUVURj8NCg0KV2UgY2FuIGRlbGF5IHRoZSBwcm9jZXNzIGFuZCBrZWVw IHRoZSBkcmFmdCBpbiB0aGUgd29ya2luZyBncm91cCBmb3Igc29tZSBtb3JlIHRpbWUuIFRoZSBv dGhlciBhcHByb2FjaCBpcyB0byBnZXQgbW9yZSBpbnB1dHMgZnJvbSBhbGwgdGhlIGludGVyZXN0 ZWQgY29tcGFuaWVzIGFuZCBmaW5kIGEgY2xvc3VyZS4NCg0KDQoNClJlZ2FyZHMNClNyaQ0KDQoN Cg0KDQpGcm9tOiBJdHN1bWEgVEFOQUtBIDx0YW5ha2FpQG50dGRvY29tby5jby5qcDxtYWlsdG86 dGFuYWthaUBudHRkb2NvbW8uY28uanA+Pg0KRGF0ZTogU3VuZGF5LCBKdW5lIDksIDIwMTMgMTE6 MTIgUE0NClRvOiBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpzZ3Vu ZGF2ZUBjaXNjby5jb20+PiwgInpob3UueGluZ3l1ZUBaVEUuQ09NLkNOPG1haWx0bzp6aG91Lnhp bmd5dWVAWlRFLkNPTS5DTj4iIDx6aG91Lnhpbmd5dWVAWlRFLkNPTS5DTjxtYWlsdG86emhvdS54 aW5neXVlQFpURS5DT00uQ04+PiwgIidCRVJSWSwgTmlnZWwgKE5pZ2VsKSciIDxuaWdlbC5iZXJy eUBBTENBVEVMLUxVQ0VOVC5DT008bWFpbHRvOm5pZ2VsLmJlcnJ5QEFMQ0FURUwtTFVDRU5ULkNP TT4+LCAiJ1dpbGQsIFBldGVyIEFsZXhhbmRlciwgVm9kYWZvbmUgREUnIiA8cGV0ZXIud2lsZEB2 b2RhZm9uZS5jb208bWFpbHRvOnBldGVyLndpbGRAdm9kYWZvbmUuY29tPj4sICdGcmFuayBZb25n IFlhbmcnIDxmcmFuay55b25nLnlhbmdARVJJQ1NTT04uQ09NPG1haWx0bzpmcmFuay55b25nLnlh bmdARVJJQ1NTT04uQ09NPj4sICInU2hpc2h1ZmVuZyAoU3VzYW4pJyIgPHN1c2FuLnNoaXNodWZl bmdASFVBV0VJLkNPTTxtYWlsdG86c3VzYW4uc2hpc2h1ZmVuZ0BIVUFXRUkuQ09NPj4sICdTaGFo YWIgTGF2YXNhbmknIDxzaGFoYWIubGF2YXNhbmlASFVBV0VJLkNPTTxtYWlsdG86c2hhaGFiLmxh dmFzYW5pQEhVQVdFSS5DT00+PiwgIidNaWx0b24sIExldyAoTlNOIC0gVVMvQXJsaW5ndG9uIEhl aWdodHMpJyIgPGxldy5taWx0b25ATlNOLkNPTTxtYWlsdG86bGV3Lm1pbHRvbkBOU04uQ09NPj4s ICInTEFOREFJUywgQlJVTk8gKEJSVU5PKSciIDxicnVuby5sYW5kYWlzQGFsY2F0ZWwtbHVjZW50 LmNvbTxtYWlsdG86YnJ1bm8ubGFuZGFpc0BhbGNhdGVsLWx1Y2VudC5jb20+PiwgImtvamkud2F0 YW5hYmUuYXpAaGl0YWNoaS5jb208bWFpbHRvOmtvamkud2F0YW5hYmUuYXpAaGl0YWNoaS5jb20+ IiA8a29qaS53YXRhbmFiZS5hekBoaXRhY2hpLmNvbTxtYWlsdG86a29qaS53YXRhbmFiZS5hekBo aXRhY2hpLmNvbT4+LCAidGFtdXJhdG9AYWouanAubmVjLmNvbTxtYWlsdG86dGFtdXJhdG9AYWou anAubmVjLmNvbT4iIDx0YW11cmF0b0Bhai5qcC5uZWMuY29tPG1haWx0bzp0YW11cmF0b0Bhai5q cC5uZWMuY29tPj4sICJqYW4ua2FsbEBuc24uY29tPG1haWx0bzpqYW4ua2FsbEBuc24uY29tPiIg PGphbi5rYWxsQG5zbi5jb208bWFpbHRvOmphbi5rYWxsQG5zbi5jb20+PiwgIk5pcmF2IFNhbG90 IChuc2Fsb3QpIiA8bnNhbG90QGNpc2NvLmNvbTxtYWlsdG86bnNhbG90QGNpc2NvLmNvbT4+LCAn UmFodWwgU3VoYXMgVmFpZHlhJyA8cmFodWx2QGp1bmlwZXIubmV0PG1haWx0bzpyYWh1bHZAanVu aXBlci5uZXQ+PiwgImpsYWdhbmllckBqdW5pcGVyLm5ldDxtYWlsdG86amxhZ2FuaWVyQGp1bmlw ZXIubmV0PiIgPGpsYWdhbmllckBqdW5pcGVyLm5ldDxtYWlsdG86amxhZ2FuaWVyQGp1bmlwZXIu bmV0Pj4sICdKZXN1cyBEZSBHcmVnb3JpbycgPGplc3VzLmRlLmdyZWdvcmlvQEVSSUNTU09OLkNP TTxtYWlsdG86amVzdXMuZGUuZ3JlZ29yaW9ARVJJQ1NTT04uQ09NPj4sICdQZXRlciBTY2htaXR0 JyA8UGV0ZXIuU2NobWl0dEBIVUFXRUkuQ09NPG1haWx0bzpQZXRlci5TY2htaXR0QEhVQVdFSS5D T00+PiwgJ0hpZGV0b3NoaSBZb2tvdGEnIDx5b2tvdGFAa2RkaWxhYnMuanA8bWFpbHRvOnlva290 YUBrZGRpbGFicy5qcD4+LCAiam91bmkubm9zcGFtQGdtYWlsLmNvbTxtYWlsdG86am91bmkubm9z cGFtQGdtYWlsLmNvbT4iIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPG1haWx0bzpqb3VuaS5ub3Nw YW1AZ21haWwuY29tPj4sICJtYXJjby5saWVic2NoQG53Lm5lY2xhYi5ldTxtYWlsdG86bWFyY28u bGllYnNjaEBudy5uZWNsYWIuZXU+IiA8bWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU8bWFpbHRv Om1hcmNvLmxpZWJzY2hAbncubmVjbGFiLmV1Pj4sICJzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24u Y29tPG1haWx0bzpzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPiIgPHN1cmVzaC5rcmlzaG5h bkBlcmljc3Nvbi5jb208bWFpbHRvOnN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+PiwgIkJh c2F2YXJhaiBQYXRpbCAoYmFzYXZwYXQpIiA8YmFzYXZwYXRAY2lzY28uY29tPG1haWx0bzpiYXNh dnBhdEBjaXNjby5jb20+Pg0KQ2M6ICJuaXNoaWRha0BudHRkb2NvbW8uY28uanA8bWFpbHRvOm5p c2hpZGFrQG50dGRvY29tby5jby5qcD4iIDxuaXNoaWRha0BudHRkb2NvbW8uY28uanA8bWFpbHRv Om5pc2hpZGFrQG50dGRvY29tby5jby5qcD4+LCAic2hpbi55b2tveWFtYS5rY0BzMS5udHRkb2Nv bW8uY29tPG1haWx0bzpzaGluLnlva295YW1hLmtjQHMxLm50dGRvY29tby5jb20+IiA8c2hpbi55 b2tveWFtYS5rY0BzMS5udHRkb2NvbW8uY29tPG1haWx0bzpzaGluLnlva295YW1hLmtjQHMxLm50 dGRvY29tby5jb20+PiwgJ0F0c3VzaGkgTWlub2t1Y2hpJyA8bWlub2t1Y2hpQG50dGRvY29tby5j by5qcDxtYWlsdG86bWlub2t1Y2hpQG50dGRvY29tby5jby5qcD4+LCAnWmhlbiBNaWFvJyA8bWlh b0BudHRkb2NvbW8uY28uanA8bWFpbHRvOm1pYW9AbnR0ZG9jb21vLmNvLmpwPj4NClN1YmplY3Q6 IFJFOiBFbmQgTWFya2VyIGVuaGFuY2VtZW50cyBmb3IgUE1JUCBVcGRhdGUgTm90aWZpY2F0aW9u DQoNCkRlYXIgU3JpLA0KDQpUaGFua3MgZm9yIHRoZSBwcm9tcHQgZmVlZGJhY2sgaGVyZS4NClNv IGlzIGl0IGNvcnJlY3QgdW5kZXJzdGFuZGluZyB0aGF0IDNHUFAgY2FuIGRlZmluZSB0aGVpciBv d24goadOb3RpZmljYXRpb24gUmVhc29uoag/DQpUaGVuIGl0oaZzIGEgZ29vZCBuZXdzIGZvciBt ZSwgYXMgd2UgZG9uoaZ0IHBvc3NpYmx5IG5lZWQgdG8gdGFrZSBhbnkgYWN0aW9uIGluIElFVEYu DQoNCg0KICAqICAgVGhlIFJlYXNvbiBDb2RlIHRoYXQgd2UgaGF2ZSBjdXJyZW50bHkgYWxsb3dz IHRoZSBMTUEgdG8gcmVxdWVzdCB0aGUgTUFHIHRvIHJlLXJlZ2lzdGVyICh0aGlzIGltcGxpY2l0 bHkgaW5jbHVkZXMgZGUtcmVnaXN0ZXIpLCBvciBqdXN0IHVwZGF0ZSB0aGUgc2Vzc2lvbiBwYXJh bWV0ZXJzLg0KVGhlIKGnRW5kIE1hcmtlcqGoIGluZGljYXRpb24gYWRkZWQgaW4gM0dQUCBpcyBu b3QgdG8gcmUvZGUtcmVnaXN0ZXIgb3IgdG8gdXBkYXRlIHRoZSBzZXNzaW9uIHBhcmFtZXRlciwg YnV0IHRvIGxldCBNQUcgdG8gYmVoYXZlIGluIGEgY2VydGFpbiB3YXkgKGUuZy4gZ2VuZXJhdGUg oadlbmQgbWFya2VyoaggcGFja2V0IHRvd2FyZHMgdGhlIHJhZGlvIGFjY2VzcykuICBDYW4gdGhl IGN1cnJlbnQgSS1EIGNvdmVyIHN1Y2ggc2NlbmFyaW8gYXMgd2VsbD8NCg0KPkl0cyBub3QgdG9v IGxhdGUsIHdlIGNhbiBjZXJ0YWlubHkgbWFrZSBjaGFuZ2VzL2FkZCBjbGFyaWZpY2F0aW9uIG5v dGVzIGJlZm9yZSBpdCBoaXRzIElFU0cgaW4gdGhlIGNvbWluZyB3ZWVrcy4NCg0KVGhlIG5leHQg M0dQUCBDVDQgbWVldGluZyB3aWxsIGJlIGluIEF1Z3VzdCAyMDEzIKFWIHNvIGlzbqGmdCBpdCBh IGJpdCB0b28gbGF0ZSB3aGVuIHNvbWUgY2hhbmdlcy9jbGFyaWZpY2F0aW9uIGFyZSBuZWVkZWQg aW4gSUVURj8NCg0KUmVnYXJkcywNCkl0c3VtYQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSXRzdW1hIFRBTkFLQSAopdCkpKvCrHqw qCkNCkdTTUEgSVJFRyBWaWNlIENoYWlyIC8gSVJFRyBQYWNrZXQgQ2hhaXINCg0KTlRUIERPQ09N TywgSW5jLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFttYWlsdG86c2d1 bmRhdmVAY2lzY28uY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDEwLCAyMDEzIDM6MDIgUE0NClRv OiBJdHN1bWEgVEFOQUtBOyB6aG91Lnhpbmd5dWVAWlRFLkNPTS5DTjxtYWlsdG86emhvdS54aW5n eXVlQFpURS5DT00uQ04+OyAnQkVSUlksIE5pZ2VsIChOaWdlbCknOyAnV2lsZCwgUGV0ZXIgQWxl eGFuZGVyLCBWb2RhZm9uZSBERSc7ICdGcmFuayBZb25nIFlhbmcnOyAnU2hpc2h1ZmVuZyAoU3Vz YW4pJzsgJ1NoYWhhYiBMYXZhc2FuaSc7ICdNaWx0b24sIExldyAoTlNOIC0gVVMvQXJsaW5ndG9u IEhlaWdodHMpJzsgTEFOREFJUywgQlJVTk8gKEJSVU5PKTsga29qaS53YXRhbmFiZS5hekBoaXRh Y2hpLmNvbTxtYWlsdG86a29qaS53YXRhbmFiZS5hekBoaXRhY2hpLmNvbT47IHRhbXVyYXRvQGFq LmpwLm5lYy5jb208bWFpbHRvOnRhbXVyYXRvQGFqLmpwLm5lYy5jb20+OyBqYW4ua2FsbEBuc24u Y29tPG1haWx0bzpqYW4ua2FsbEBuc24uY29tPjsgTmlyYXYgU2Fsb3QgKG5zYWxvdCk7ICdSYWh1 bCBTdWhhcyBWYWlkeWEnOyBqbGFnYW5pZXJAanVuaXBlci5uZXQ8bWFpbHRvOmpsYWdhbmllckBq dW5pcGVyLm5ldD47ICdKZXN1cyBEZSBHcmVnb3Jpbyc7ICdQZXRlciBTY2htaXR0JzsgJ0hpZGV0 b3NoaSBZb2tvdGEnOyBqb3VuaS5ub3NwYW1AZ21haWwuY29tPG1haWx0bzpqb3VuaS5ub3NwYW1A Z21haWwuY29tPjsgbWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU8bWFpbHRvOm1hcmNvLmxpZWJz Y2hAbncubmVjbGFiLmV1Pjsgc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTxtYWlsdG86c3Vy ZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT47IEJhc2F2YXJhaiBQYXRpbCAoYmFzYXZwYXQpDQpD YzogbmlzaGlkYWtAbnR0ZG9jb21vLmNvLmpwPG1haWx0bzpuaXNoaWRha0BudHRkb2NvbW8uY28u anA+OyBzaGluLnlva295YW1hLmtjQHMxLm50dGRvY29tby5jb208bWFpbHRvOnNoaW4ueW9rb3lh bWEua2NAczEubnR0ZG9jb21vLmNvbT47ICdBdHN1c2hpIE1pbm9rdWNoaSc7IFpoZW4gTWlhbw0K U3ViamVjdDogUmU6IEVuZCBNYXJrZXIgZW5oYW5jZW1lbnRzIGZvciBQTUlQIFVwZGF0ZSBOb3Rp ZmljYXRpb24NCg0KSGkgSXRzdW1hLXNhbiwNCg0KKyBCYXNhdmFyYWoNCg0KSSBoYWQgYSBjaGF0 IHdpdGggWW9rb3RhLXNhbiBvbiB0aGlzIGFuZCBoZXJlIGlzIG15IHZpZXcgb24gdGhpcyByZXF1 aXJlbWVudC4NCg0KICAqICAgVXBkYXRlIE5vdGlmaWNhdGlvbiAoVVBOKSBwcm92aWRlcyB0aGUg YmFzaWMgc2VtYW50aWNzIGZvciBMTUEgaW5pdGlhdGVkIG5vdGlmaWNhdGlvbiBtZXNzYWdlcw0K ICAqICAgQW55IG9mIHRoZSBNb2JpbGl0eSBIZWFkZXIgb3B0aW9ucyBkZWZpbmVkIGZvciBQTUlQ djYgc2lnbmFsaW5nIG1lc3NhZ2VzIGNhbiBiZSBjYXJyaWVkIGluIHRoZSBVUE4vVVBOQSBtZXNz YWdlLCBpbmNsdWRpbmcgUkZDNTA5NCBWU0UNCiAgKiAgIENUNCBjYW4gZGVmaW5lIGEgbmV3IDNH UFAgVlNFIGJhc2VkIG9uIFJGQzUwOTQgZm9yIHN1cHBvcnRpbmcgRW5kIE1hcmtlciBlbmhhbmNl bWVudC4gVGhpcyBiZWluZyB2ZXJ5IDNHUFAgc3BlY2lmaWMsIGl0IG1ha2VzIHNlbnNlIG5vdCB0 byBkZWZpbmUgYSBnZW5lcmljIElFVEYgTUggb3B0aW9uIGZvciB0aGlzDQogICogICBUaGUgUmVh c29uIENvZGUgdGhhdCB3ZSBoYXZlIGN1cnJlbnRseSBhbGxvd3MgdGhlIExNQSB0byByZXF1ZXN0 IHRoZSBNQUcgdG8gcmUtcmVnaXN0ZXIgKHRoaXMgaW1wbGljaXRseSBpbmNsdWRlcyBkZS1yZWdp c3RlciksIG9yIGp1c3QgdXBkYXRlIHRoZSBzZXNzaW9uIHBhcmFtZXRlcnMuDQogICogICBUaGUg M0dQUCBWU0Ugd2hlbiBjYXJyaWVkIHdpdGggb25lIG9mIHRoZSBhYm92ZSB0d28gUmVhc29uIENv ZGVzLCBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgdGhlIE1BRyB0byBoYW5kbGUgdGhpcyBjb3Jy ZWN0bHkuIEJ1dCwgaWYgYXJlIGV4cGVjdGluZyBzb21lIG5ldyBiZWhhdmlvciwgd2UgY2FuIGNl cnRhaW5seSBkZWZpbmUgYSBuZXcgUmVhc29uIENvZGUgYW5kIHNwZWNpZnkgdGhhdCBBY3Rpb24u DQoNCkl0cyBub3QgdG9vIGxhdGUsIHdlIGNhbiBjZXJ0YWlubHkgbWFrZSBjaGFuZ2VzL2FkZCBj bGFyaWZpY2F0aW9uIG5vdGVzIGJlZm9yZSBpdCBoaXRzIElFU0cgaW4gdGhlIGNvbWluZyB3ZWVr cy4gIEJ1dCwgd2hhdCB3ZSBoYXZlIG1heSBiZSBzdWZmaWNpZW50Lg0KDQoNClJlZ2FyZHMNClNy aQ0KDQoNCg0KRnJvbTogSXRzdW1hIFRBTkFLQSA8dGFuYWthaUBudHRkb2NvbW8uY28uanA8bWFp bHRvOnRhbmFrYWlAbnR0ZG9jb21vLmNvLmpwPj4NCkRhdGU6IFN1bmRheSwgSnVuZSA5LCAyMDEz IDEwOjIzIFBNDQpUbzogInpob3UueGluZ3l1ZUBaVEUuQ09NLkNOPG1haWx0bzp6aG91Lnhpbmd5 dWVAWlRFLkNPTS5DTj4iIDx6aG91Lnhpbmd5dWVAWlRFLkNPTS5DTjxtYWlsdG86emhvdS54aW5n eXVlQFpURS5DT00uQ04+PiwgIidCRVJSWSwgTmlnZWwgKE5pZ2VsKSciIDxuaWdlbC5iZXJyeUBB TENBVEVMLUxVQ0VOVC5DT008bWFpbHRvOm5pZ2VsLmJlcnJ5QEFMQ0FURUwtTFVDRU5ULkNPTT4+ LCAiJ1dpbGQsIFBldGVyIEFsZXhhbmRlciwgVm9kYWZvbmUgREUnIiA8cGV0ZXIud2lsZEB2b2Rh Zm9uZS5jb208bWFpbHRvOnBldGVyLndpbGRAdm9kYWZvbmUuY29tPj4sICdGcmFuayBZb25nIFlh bmcnIDxmcmFuay55b25nLnlhbmdARVJJQ1NTT04uQ09NPG1haWx0bzpmcmFuay55b25nLnlhbmdA RVJJQ1NTT04uQ09NPj4sICInU2hpc2h1ZmVuZyAoU3VzYW4pJyIgPHN1c2FuLnNoaXNodWZlbmdA SFVBV0VJLkNPTTxtYWlsdG86c3VzYW4uc2hpc2h1ZmVuZ0BIVUFXRUkuQ09NPj4sICdTaGFoYWIg TGF2YXNhbmknIDxzaGFoYWIubGF2YXNhbmlASFVBV0VJLkNPTTxtYWlsdG86c2hhaGFiLmxhdmFz YW5pQEhVQVdFSS5DT00+PiwgIidNaWx0b24sIExldyAoTlNOIC0gVVMvQXJsaW5ndG9uIEhlaWdo dHMpJyIgPGxldy5taWx0b25ATlNOLkNPTTxtYWlsdG86bGV3Lm1pbHRvbkBOU04uQ09NPj4sICJM QU5EQUlTLCBCUlVOTyAoQlJVTk8pIiA8YnJ1bm8ubGFuZGFpc0BhbGNhdGVsLWx1Y2VudC5jb208 bWFpbHRvOmJydW5vLmxhbmRhaXNAYWxjYXRlbC1sdWNlbnQuY29tPj4sICJrb2ppLndhdGFuYWJl LmF6QGhpdGFjaGkuY29tPG1haWx0bzprb2ppLndhdGFuYWJlLmF6QGhpdGFjaGkuY29tPiIgPGtv amkud2F0YW5hYmUuYXpAaGl0YWNoaS5jb208bWFpbHRvOmtvamkud2F0YW5hYmUuYXpAaGl0YWNo aS5jb20+PiwgInRhbXVyYXRvQGFqLmpwLm5lYy5jb208bWFpbHRvOnRhbXVyYXRvQGFqLmpwLm5l Yy5jb20+IiA8dGFtdXJhdG9AYWouanAubmVjLmNvbTxtYWlsdG86dGFtdXJhdG9AYWouanAubmVj LmNvbT4+LCAiamFuLmthbGxAbnNuLmNvbTxtYWlsdG86amFuLmthbGxAbnNuLmNvbT4iIDxqYW4u a2FsbEBuc24uY29tPG1haWx0bzpqYW4ua2FsbEBuc24uY29tPj4sICJOaXJhdiBTYWxvdCAobnNh bG90KSIgPG5zYWxvdEBjaXNjby5jb208bWFpbHRvOm5zYWxvdEBjaXNjby5jb20+PiwgJ1JhaHVs IFN1aGFzIFZhaWR5YScgPHJhaHVsdkBqdW5pcGVyLm5ldDxtYWlsdG86cmFodWx2QGp1bmlwZXIu bmV0Pj4sICJqbGFnYW5pZXJAanVuaXBlci5uZXQ8bWFpbHRvOmpsYWdhbmllckBqdW5pcGVyLm5l dD4iIDxqbGFnYW5pZXJAanVuaXBlci5uZXQ8bWFpbHRvOmpsYWdhbmllckBqdW5pcGVyLm5ldD4+ LCAnSmVzdXMgRGUgR3JlZ29yaW8nIDxqZXN1cy5kZS5ncmVnb3Jpb0BFUklDU1NPTi5DT008bWFp bHRvOmplc3VzLmRlLmdyZWdvcmlvQEVSSUNTU09OLkNPTT4+LCAnUGV0ZXIgU2NobWl0dCcgPFBl dGVyLlNjaG1pdHRASFVBV0VJLkNPTTxtYWlsdG86UGV0ZXIuU2NobWl0dEBIVUFXRUkuQ09NPj4s ICdIaWRldG9zaGkgWW9rb3RhJyA8eW9rb3RhQGtkZGlsYWJzLmpwPG1haWx0bzp5b2tvdGFAa2Rk aWxhYnMuanA+PiwgImpvdW5pLm5vc3BhbUBnbWFpbC5jb208bWFpbHRvOmpvdW5pLm5vc3BhbUBn bWFpbC5jb20+IiA8am91bmkubm9zcGFtQGdtYWlsLmNvbTxtYWlsdG86am91bmkubm9zcGFtQGdt YWlsLmNvbT4+LCAibWFyY28ubGllYnNjaEBudy5uZWNsYWIuZXU8bWFpbHRvOm1hcmNvLmxpZWJz Y2hAbncubmVjbGFiLmV1PiIgPG1hcmNvLmxpZWJzY2hAbncubmVjbGFiLmV1PG1haWx0bzptYXJj by5saWVic2NoQG53Lm5lY2xhYi5ldT4+LCAic3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTxt YWlsdG86c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4iIDxzdXJlc2gua3Jpc2huYW5AZXJp Y3Nzb24uY29tPG1haWx0bzpzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPj4sIFNyaSBHdW5k YXZlbGxpIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+DQpD YzogIm5pc2hpZGFrQG50dGRvY29tby5jby5qcDxtYWlsdG86bmlzaGlkYWtAbnR0ZG9jb21vLmNv LmpwPiIgPG5pc2hpZGFrQG50dGRvY29tby5jby5qcDxtYWlsdG86bmlzaGlkYWtAbnR0ZG9jb21v LmNvLmpwPj4sICJzaGluLnlva295YW1hLmtjQHMxLm50dGRvY29tby5jb208bWFpbHRvOnNoaW4u eW9rb3lhbWEua2NAczEubnR0ZG9jb21vLmNvbT4iIDxzaGluLnlva295YW1hLmtjQHMxLm50dGRv Y29tby5jb208bWFpbHRvOnNoaW4ueW9rb3lhbWEua2NAczEubnR0ZG9jb21vLmNvbT4+LCAnQXRz dXNoaSBNaW5va3VjaGknIDxtaW5va3VjaGlAbnR0ZG9jb21vLmNvLmpwPG1haWx0bzptaW5va3Vj aGlAbnR0ZG9jb21vLmNvLmpwPj4sIFpoZW4gTWlhbyA8bWlhb0BudHRkb2NvbW8uY28uanA8bWFp bHRvOm1pYW9AbnR0ZG9jb21vLmNvLmpwPj4NClN1YmplY3Q6IEVuZCBNYXJrZXIgZW5oYW5jZW1l bnRzIGZvciBQTUlQIFVwZGF0ZSBOb3RpZmljYXRpb24NCg0KRGVhciBQTUlQIEV4cGVydHMgaW4g Q1Q0IGFuZCB0aGUgRWRpdG9ycyBvZiBQTUlQIFVwZGF0ZSBOb3RpZmljYXRpb24gSS1ELg0KDQpJ oaZkIGxpa2UgdG8gZHJhdyB5b3VyIGF0dGVudGlvbiBvbiB0aGUgYXR0YWNoZWQgUmVsLTEyIENS cyB0byAzR1BQIFRTMjMuNDAxIGFuZCBUUzIzLjQwMiwgd2hpY2ggd2VyZSBhZ3JlZWQgaW4gU0Ey Izk3IGEgY291cGxlIHdlZWtzIGFnby4gVGhlc2UgQ1JzIGVuaGFuY2VzIEdUUC9QTUlQIHByb3Rv Y29scyB0byBhZGQgdGhlIHN1cHBvcnQgb2YgoadlbmQgbWFya2VyoagsIGFuZCBzaW5jZSBJoaZt IHBhcnRpY3VsYXJseSBjb25jZXJuZWQgYWJvdXQgaG93IHRvIHByb2dyZXNzIHRoZSBQTUlQIFN0 YWdlIDMsIEkgYXBwcmVjaWF0ZSB5b3VyIHZpZXdzIGhlcmUuDQoNCldlIChET0NPTU8pIGJlbGll dmUgdGhhdCB0aGlzIGVuaGFuY2VtZW50IGNhbiBiZSBkb25lIHVzaW5nIFBNSVAgVXBkYXRlIE5v dGlmaWNhdGlvbi4gIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBXRyBMYXN0IENhbGwgZm9yIHRo aXMgSS1EIGlzIGluIHByb2dyZXNzIGluIElFVEYsIGFuZCBJoaZtIG9mIHRoZSBvcGluaW9uIHRo YXQgY29vcmRpbmF0aW9uIGJldHdlZW4gM0dQUCBhbmQgSUVURiBtaWdodCBiZSBuZWNlc3Nhcnku DQoNClNvIEmhpmQgbGlrZSB0byBraW5kbHkgYXNrIHlvdXIgdmlld3Mgb246DQoNCi0gICAgICAg V2hldGhlciB0aGVzZSBhZGRpdGlvbnMgY2FuIGJlIHJlYWxpemVkIHdpdGhvdXQgaW1wYWN0aW5n IElFVEYgVXBkYXRlIE5vdGlmaWNhdGlvbiBJLUQ/DQoNCi0gICAgICAgSWYgSUVURiBpbXBhY3Qg aXMgaW5ldml0YWJsZSwgY2FuIHdlIHJhaXNlIHRoaXMgZGlyZWN0bHkgaW4gSUVURiBhbmQgc3Rv cCB0aGUgcHJvY2VzcyB1bnRpbCBDVDQgYWdyZWVzIG9uIHRoZSB3YXkgZm9yd2FyZD8NCg0KRm9y IHRoZSBmaXJzdCBxdWVzdGlvbiwgdGhlIG9ubHkgaW1wYWN0IG9uIHRoZSBJLUQgSaGmbSBzZWVp bmcgaGVyZSBpcyBhZGRpbmcgYSBuZXcgoadOb3RpZmljYXRpb24gUmVhc29uoaggdmFsdWUuDQpJ oaZkIGxpa2UgdG8ga25vdyBpZiBhbnkgYWRkaXRpb24gb24goadOb3RpZmljYXRpb24gUmVhc29u oaggaGVhZGVyIG5lZWRzIGFueSBJRVRGIHdvcmsuDQpPciBjYW4gdGhpcyBiZSBzcGVjaWZpZWQg aW4gM0dQUCAoYW5kIHN1YnNlcXVlbnQgSUFOQSByZWdpc3RyYXRpb24pIG9ubHk/DQoNCkJlc3Qg UmVnYXJkcywNCkl0c3VtYQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KSXRzdW1hIFRBTkFLQSAopdCkpKvCrHqwqCkNCkdTTUEgSVJF RyBWaWNlIENoYWlyIC8gSVJFRyBQYWNrZXQgQ2hhaXINCg0KTlRUIERPQ09NTywgSW5jLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_24C0F3E22276D9438D6F366EB89FAEA8102D83EFxmbalnx03ciscoc_ Content-Type: text/html; charset="big5" Content-ID: <0703969D9823464C8C69A797E523CF8E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
FYI. Discussion with 3GPP SA2/CT4 members on adding a new status code = value to the Update Notification draft.

This draft has just finished WG LC call, but we plan to make this chan= ge (adding a Reason Code) and keep the semantics clean.

Comments welcome.

Regards
Sri





From: Itsuma TANAKA <tanakai@nttdocomo.co.jp>
Date: Monday, June 10, 2013 1:12 AM=
To: Sri Gundavelli <sgundave@cisco.com>, "zhou.xingyue@ZTE.COM.CN" <zhou.xingyue@ZTE.COM.CN>, "'BERRY, Nigel (Nigel)'" <nigel.berry@ALCATEL-LUCENT.COM>, "'Wild, Peter A= lexander, Vodafone DE'" <peter.wild@vodafone.com>, 'Frank Yong Yang' <frank.yong.yang@ERICSSON.COM>, "'Shishufeng (Susan)'" <susan.shishufeng@HUAWEI.COM>, 'Shahab Lavasani' <shahab.lavasani@HUAWEI.COM>,= "'Milton, Lew (NSN - US/Arlington Heights)'" <lew.milton@NSN.COM>, "'LANDAIS, BRUNO (BRUNO)'" <bruno.landais@alcatel-lucent.com>, "koji.watanabe.az@hitachi.com&q= uot; <koji.watanabe.az@h= itachi.com>, "tamurato@aj.jp.nec.com= " <tamurato@aj.jp.nec.com= >, "jan.kall@nsn.com&qu= ot; <jan.kall@nsn.com>, "= ;Nirav Salot (nsalot)" <nsalot@cisco.= com>, 'Rahul Suhas Vaidya' <rahulv@juniper.net>, "jlaganier@juniper.net" <jlaganier@juniper.net>, 'Jesus De Gregorio' <= jesus.de.gregorio@ERICSSON.COM>, 'Peter Schmitt' <Peter.Schmitt@HUAWEI.COM>, 'Hidetoshi Y= okota' <yokota@kddilabs.jp>= , "jouni.nospam@gmail.com= " <jouni.nospam@gmail.com= >, "marco.liebsch= @nw.neclab.eu" <m= arco.liebsch@nw.neclab.eu>, "suresh.krishnan@eric= sson.com" <sure= sh.krishnan@ericsson.com>, "Basavaraj Patil (basavpat)" &l= t;basavpat@cisco.com>
Cc: "nishidak@nttdocomo.co.jp" <nishidak@nttdocomo.co.jp>, "shin.yokoyama.kc@s1.nttdocomo= .com" <shin.yokoyama.kc@= s1.nttdocomo.com>, 'Atsushi Minokuchi' <minokuchi@nttdocomo.co.jp>, 'Zhen Miao' <miao@nttdocomo.co.jp>
Subject: RE: End Marker enhancement= s for PMIP Update Notification

Dear Sri, all,

 

Many thanks=A1K<= /o:p>

First of all we=A1=A6= re NOT thinking about introducing a new Reason value specific to =A1=A7end = marker=A1=A8.

And we=A1=A6re ok to = re-use the existing Reason value (i.e. =A1=A7UPDATE-SESSION-PARAMETERS=A1= =A8) if everybody is happy with it.

And I also fully agre= e with your statement that =A1=A7the option/use-case should be broadly applicable beyond 3GPP system=A1=A8=

 

>if this does not sound like a clean approach, we can certainly define a new Status Code, which is "Vendor-Specific = Reason (3)".   The peer can handle the UPN message based on that = vendor-specific option. Is this what you are thinking ? 

 

But actually I like y= our idea of adding a generic new value (=A1=A7Vendor-Specific Reason (3)=A1= =A8), because I sense there=A1=A6s a possibility that:

1.      CT4= argues re-using existing one is not clean

2.     There may= be new enhancements in the future which might require addition of new caus= e value

So if we could have s= omething generic in the I-D, I think this makes it pretty much future proof= .

If we could do that a= ddition now, then I think it=A1=A6s also good from IETF procedure point of = view (I mean less delay in the process=A1Kas we don=A1=A6t need to wait for CT4 discussion)

 

What do you think? I= =A1=A6d like to also invite comments from other companies=A1K

 

Regards,

Itsuma

 

------------------------------------= --------------------

Itsuma TANAKA (=A5=D0=A4=A4=AB=C2=ACz=B0=A8)

GSMA IREG Vice Chair / IREG Packet C= hair

 

NTT DOCOMO, Inc.

------------------------------------= --------------------

 

 

From: Sri Gundavelli (sg= undave) [mailto:sgundave@cisco.com]
Sent: Monday, June 10, 2013 4:31 PM
To: Itsuma TANAKA; zhou.x= ingyue@ZTE.COM.CN; 'BERRY, Nigel (Nigel)'; 'Wild, Peter Alexander, Voda= fone DE'; 'Frank Yong Yang'; 'Shishufeng (Susan)'; 'Shahab Lavasani'; 'Milt= on, Lew (NSN - US/Arlington Heights)'; 'LANDAIS, BRUNO (BRUNO)'; = koji.watanabe.az@hitachi.com; tamurato@aj.jp.nec.com; jan.kall@nsn.com; Nirav Salot (nsalot); 'Rahul Suhas Vaidya'; jlaganier@juniper.net; 'Jesus De Gregorio'; 'Peter Schmitt'; 'Hidetoshi= Yokota'; jouni.nospam@gmail.com; marco.liebsch@nw.neclab.eu; suresh.krishnan@ericsson.com; Basavaraj Patil (basavpat)
Cc: nishidak@nttdocomo.c= o.jp; shin.yokoyama.kc@s1.nt= tdocomo.com; 'Atsushi Minokuchi'; 'Zhen Miao'
Subject: Re: End Marker enhancements for PMIP Update Notification

 

Hi Itsuma-san,

 

Thanks for your response.

 

> So is it correct understanding that 3GPP can define their own =A1=A7Notificat= ion Reason=A1=A8?

 

We were not thinking of defi= ning a Reason Code for this outside the Vendor-Specific option.

 

The Reason Code in the UPN m= essage when this Vendor-specific option is included can be "UPDATE-SESSION-PARAMETERS&q= uot;, which does not require the peer to send a= new PBU, but instead requires it to update the session state. That update = and the associated action is what the V= endor-Specific option defines (when present).

 

The presence of the Vendor-S= pecific option hints the peer to conform to a specific behavior and that be= havior is what CT4 defines. If there are multiple Actions associated with this Vendor-specific option, the option i= tself can define a vendor specific Action/Reason Code.

 

But, if this does not sound = like a clean approach, we can certainly define a new Status Code, which is = "Vendor-Specific Reason (3)".   The peer can handle the UPN message based on that vendor-specific option. Is this w= hat you are thinking ? 

 

But, if the Reason Code need= s to hint specifically to "End Marker" use-case, then IMO, the op= tion/use-case should be broadly applicable beyond 3GPP system. Easier approach is to contain the usecase/behavior/action to = the vendor-specific option and keep this to 3GPP.

 

 

> The next 3GPP CT= 4 meeting will be in August 2013 =A1V so isn=A1=A6t it a bit too late when = some changes/clarification are needed in IETF?

 

We can delay the process and= keep the draft in the working group for some more time. The other approach= is to get more inputs from all the interested companies and find a closure.

 

 

 

Regards

Sri

 

 

 

 

From: Itsuma TANAKA <tanakai@nttdocomo.co.jp>
Date: Sunday, June 9, 2013 11:12 PM
To: Sri Gundavelli <sgundav= e@cisco.com>, "zhou.= xingyue@ZTE.COM.CN" <zhou.xingyue@ZTE.COM.CN>, "'BERRY, Nigel (Nigel)'" <nigel.berry@ALCATEL-LUCENT.= COM>, "'Wild, Peter Alexander, Vodafone DE'" <peter.wild@vodafone.com>, 'Frank Yong Yang' &l= t;frank.yong.yang@ERICSSON.= COM>, "'Shishufeng (Susan)'" <susan.shishufeng@HUAWEI.COM>, 'Shahab Lavasani' <shahab= .lavasani@HUAWEI.COM>, "'Milton, Lew (NSN - US/Arlington Height= s)'" <lew.milton@NSN.COM&= gt;, "'LANDAIS, BRUNO (BRUNO)'" <bruno.landais@alcatel-lucent.com>, "koji.watanabe.az@hit= achi.com" <koji= .watanabe.az@hitachi.com>, "tamurato@aj.jp.nec.com" <tamurato@aj.jp.nec.com>, "jan.kall@nsn.com" <<= a href=3D"mailto:jan.kall@nsn.com">jan.kall@nsn.com>, "Nirav Sa= lot (nsalot)" <nsalot@cisco.com= >, 'Rahul Suhas Vaidya' <ra= hulv@juniper.net>, "jlaganier@juniper.net&q= uot; <jlaganier@juniper.net= >, 'Jesus De Gregorio' <jesus.de.gregorio@ERICSSON.COM>, 'Peter Schmitt' <Peter.Schmitt@HUAWEI.COM>, 'Hidetoshi Yokota' <yokota= @kddilabs.jp>, "jouni= .nospam@gmail.com" <j= ouni.nospam@gmail.com>, "marco.liebsch@nw.necla= b.eu" <marco.lieb= sch@nw.neclab.eu>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>, "Basavaraj Patil (basavpat)" <basavpat@cisco.com>
Cc: "nishidak@nttdo= como.co.jp" <nishid= ak@nttdocomo.co.jp>, "shin.yokoyama.kc@s1.nttdocomo.com" <shin.yokoyama.kc@s1.nttdocomo.com= >, 'Atsushi Minokuchi' <minok= uchi@nttdocomo.co.jp>, 'Zhen Miao' <miao@nttdocomo.co.jp>
Subject: RE: End Marker enhancements for PMIP Update Notification

 

Dear Sri,

 

Thanks for the prompt= feedback here.

So is it correct unde= rstanding that 3GPP can define their own =A1=A7Notification Reason=A1=A8?

Then it=A1=A6s a good= news for me, as we don=A1=A6t possibly need to take any action in IETF.

 

  • The Reason Code that we have currently allows the LMA to request = the MAG to re-register (this implicitly includes de-register), or just upda= te the session parameters.

The =A1=A7End Marker= =A1=A8 indication added in 3GPP is not to re/de-register or to update the s= ession parameter, but to let MAG to behave in a certain way (e.g. generate =A1=A7end marker=A1=A8 packet towards the radio access)= .  Can the current I-D cover such scenario as well?

 

>Its not too late, we can= certainly make changes/add clarification notes before it hits IESG in the = coming weeks.<= /span>

 

The next 3GPP CT4 mee= ting will be in August 2013 =A1V so isn=A1=A6t it a bit too late when some = changes/clarification are needed in IETF?

 

Regards,

Itsuma

 

------------------------------------= --------------------=

Itsuma TANAKA (=A5=D0=A4=A4=AB=C2=ACz=B0=A8)

GSMA IREG Vice Chair / IREG Packet C= hair

 

NTT DOCOMO, Inc.

------------------------------------= --------------------=

 

 

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Monday, June 10, 2013 3:02 PM
To: Itsuma TANAKA; zhou.x= ingyue@ZTE.COM.CN; 'BERRY, Nigel (Nigel)'; 'Wild, Peter Alexander, Voda= fone DE'; 'Frank Yong Yang'; 'Shishufeng (Susan)'; 'Shahab Lavasani'; 'Milt= on, Lew (NSN - US/Arlington Heights)'; LANDAIS, BRUNO (BRUNO); ko= ji.watanabe.az@hitachi.com; tamurato@aj.jp.nec.com; jan.kall@nsn.com; Nirav Salot (nsalot); 'Rahul Suhas Vaidya'; jlaganier@juniper.net; 'Jesus De Gregorio'; 'Peter Schmitt'; 'Hidetoshi= Yokota'; jouni.nospam@gmail.com; marco.liebsch@nw.neclab.eu; suresh.krishnan@ericsson.com; Basavaraj Patil (basavpat)
Cc: nishidak@nttdocomo.c= o.jp; shin.yokoyama.kc@s1.nt= tdocomo.com; 'Atsushi Minokuchi'; Zhen Miao
Subject: Re: End Marker enhancements for PMIP Update Notification

 

Hi Itsuma-san,

 

+ Basavaraj

 

I had a chat with Yokota-san= on this and here is my view on this requirement.

  • Update Notification (UPN) provides the basic semantics for LMA in= itiated notification messages=
  • Any of the Mobility Header options defined for PMIPv6 signaling m= essages can be carried in the UPN/UPNA message, including RFC5094 VSE
  • CT4 can define a new 3GPP VSE based on RFC5094 for supporting End= Marker enhancement. This being very 3GPP specific, it makes sense not to d= efine a generic IETF MH option for this
  • The Reason Code that we have currently allows the LMA to request = the MAG to re-register (this implicitly includes de-register), or just upda= te the session parameters.
  • The 3GPP VSE when carried with one of the above two Reason Codes,= should be sufficient for the MAG to handle this correctly. But, if ar= e expecting some new behavior, we can certainly define a new Reason Code and specify that Action.

 

Its not too late, we can cer= tainly make changes/add clarification notes before it hits IESG in the comi= ng weeks.  But, what we have may be sufficient.

 

 

Regards

Sri

 

 

 

From: Itsuma TANAKA <tanakai@nttdocomo.co.jp>
Date: Sunday, June 9, 2013 10:23 PM
To: "zhou.xingyue@ZT= E.COM.CN" <zhou.xing= yue@ZTE.COM.CN>, "'BERRY, Nigel (Nigel)'" <nigel.berry@ALCATEL-LUCENT.COM>= ;, "'Wild, Peter Alexander, Vodafone DE'" <peter.wild@vodafone.com>, 'Frank Yong Yang' &l= t;frank.yong.yang@ERICSSON.= COM>, "'Shishufeng (Susan)'" <susan.shishufeng@HUAWEI.COM>, 'Shahab Lavasani' <shahab= .lavasani@HUAWEI.COM>, "'Milton, Lew (NSN - US/Arlington Height= s)'" <lew.milton@NSN.COM&= gt;, "LANDAIS, BRUNO (BRUNO)" <bruno.landais@alcatel-lucent.com>, "koji.watanabe.az@hit= achi.com" <koji= .watanabe.az@hitachi.com>, "tamurato@aj.jp.nec.com" <tamurato@aj.jp.nec.com>, "jan.kall@nsn.com" <<= a href=3D"mailto:jan.kall@nsn.com">jan.kall@nsn.com>, "Nirav Sa= lot (nsalot)" <nsalot@cisco.com= >, 'Rahul Suhas Vaidya' <ra= hulv@juniper.net>, "jlaganier@juniper.net&q= uot; <jlaganier@juniper.net= >, 'Jesus De Gregorio' <jesus.de.gregorio@ERICSSON.COM>, 'Peter Schmitt' <Peter.Schmitt@HUAWEI.COM>, 'Hidetoshi Yokota' <yokota= @kddilabs.jp>, "jouni= .nospam@gmail.com" <j= ouni.nospam@gmail.com>, "marco.liebsch@nw.necla= b.eu" <marco.lieb= sch@nw.neclab.eu>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>, Sri Gundavelli <sgundave@cisco.co= m>
Cc: "nishidak@nttdo= como.co.jp" <nishid= ak@nttdocomo.co.jp>, "shin.yokoyama.kc@s1.nttdocomo.com" <shin.yokoyama.kc@s1.nttdocomo.com= >, 'Atsushi Minokuchi' <minok= uchi@nttdocomo.co.jp>, Zhen Miao <miao@nttdocomo.co.jp>
Subject: End Marker enhancements for PMIP Update Notification=

 

Dear PMIP Experts in = CT4 and the Editors of PMIP Update Notification I-D.

 

I=A1=A6d like to draw= your attention on the attached Rel-12 CRs to 3GPP TS23.401 and TS23.402, w= hich were agreed in SA2#97 a couple weeks ago. These CRs enhances GTP/PMIP protocols to add the support of =A1=A7end mark= er=A1=A8, and since I=A1=A6m particularly concerned about how to progress t= he PMIP Stage 3, I appreciate your views here.

 

We (DOCOMO) believe t= hat this enhancement can be done using PMIP Update Notification.  My understanding is that WG Last Cal= l for this I-D is in progress in IETF, and I=A1=A6m of the opinion that coo= rdination between 3GPP and IETF might be necessary.

 

So I=A1=A6d like to k= indly ask your views on:<= o:p>

-  &nbs= p;    Whether t= hese additions can be realized without impacting IETF Update Notification I= -D?

-  &nbs= p;    If IETF i= mpact is inevitable, can we raise this directly in IETF and stop the proces= s until CT4 agrees on the way forward?

 

For the first questio= n, the only impact on the I-D I=A1=A6m seeing here is adding a new =A1=A7No= tification Reason=A1=A8 value.

I=A1=A6d like to know= if any addition on =A1=A7Notification Reason=A1=A8 header needs any IETF w= ork.

Or can this be specif= ied in 3GPP (and subsequent IANA registration) only?

 

Best Regards,<= span lang=3D"EN-US" style=3D"color:black">

Itsuma

 

------------------------------------= --------------------=

Itsuma TANAKA (=A5=D0=A4=A4=AB=C2=ACz=B0=A8)

GSMA IREG Vice Chair / IREG Packet C= hair

 

NTT DOCOMO, Inc.

------------------------------------= --------------------=

--_000_24C0F3E22276D9438D6F366EB89FAEA8102D83EFxmbalnx03ciscoc_-- From Marco.Liebsch@neclab.eu Mon Jun 17 08:55:21 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6013E21F9CEB for ; Mon, 17 Jun 2013 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss3Dbc9Eyh86 for ; Mon, 17 Jun 2013 08:55:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B63EE21F9CD4 for ; Mon, 17 Jun 2013 08:55:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4E581104567; Mon, 17 Jun 2013 17:54:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4XimKPGOM1Q; Mon, 17 Jun 2013 17:54:56 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 31F8B104582; Mon, 17 Jun 2013 17:54:41 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.234]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 17 Jun 2013 17:55:00 +0200 From: Marco Liebsch To: Ahmad Muhanna , "netext@ietf.org" Thread-Topic: Review Comments on: draft-ietf-netext-pmip6-qos-02 Thread-Index: AQHOX8Ztyr3m4jYzDECTM8RQi1fIwJk6FdKQ Date: Mon, 17 Jun 2013 15:54:01 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D552CD2D7@DAPHNIS.office.hd> References: <3359F724933DFD458579D24EAC7690988B231081@Redwood.usa.awardsolutions.com> In-Reply-To: <3359F724933DFD458579D24EAC7690988B231081@Redwood.usa.awardsolutions.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Basavaraj Patil Subject: Re: [netext] Review Comments on: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:55:21 -0000 Hi Ahmad, thanks a lot for your detailed comments and proposals. Please see inline for feedback. >-----Original Message----- >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf O= f >Ahmad Muhanna >Sent: Sonntag, 2. Juni 2013 21:21 >To: netext@ietf.org >Cc: Basavaraj Patil >Subject: [netext] Review Comments on: draft-ietf-netext-pmip6-qos-02 > >Hi Raj and authors, > >I have reviewed this draft and I have the below comments. > >General Comment: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >I have found it difficult to follow this document differentiation between = IP >session, IP flows, Mobility Session with respect to QoS. Since this docume= nt >reference 3GPP specification for the purpose of QoS, we realize that QoS (= in >3GPP) is enforced at the level of a bearer. Thus, when we talk about IP se= ssion, is >that a single bearer or all types of traffic/flows is carried over this IP= session. >May be the question is: what is the equivalent of a bearer in PMIPv6? Then= we >should make sure that we use that definition when referring to QoS >enforcement. I would not try to map the bearer concept, which applies to cellular networ= ks, to IP tunneling as used by PMIP. A PMIP tunnel is shared even by multiple u= sers, whereas the bearer is established per MN and per QoS. I'd rather add more t= ext about how QoS differentiation should be enabled on a PMIP tunnel. In current cell= ular systems, mapping of flows to a per MN and per-QoS bearer is performed on the downlin= k after the termination of the PMIP tunnel, i.e. at the MAG. So, no bearer as= sumed on PMIP even in cellular networks. Scope of the spec is to enable QoS differen= tiation by means of DSCPs on the PMIP tunnel and opt for mapping of QoS rules to non-cellula= r access technology specific QoS. > >After reading on, section 4.1., mentions that the QoS is applied at three = different >levels, IP flow, Mobility Session, or per MN. >May be it is a good idea to have this mentioned upfront in the introductio= n >section in order to set the stage correctly. In addition somehow, this doc= ument >needs to provide the detailed logic to differentiate between the three cas= es. Fully agree to that point and we addressed past comments on this mainly in = the message format description. The general parts, such as the Intro, lack in clear text, which we'll add in the updated version. Thanks again for the hi= nt. > > >Editorial: >Comment No. 1: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > (a) Maintenance of QoS classification during a handover between > cellular radio access and WLAN access by means of establishing QoS > policies in the handover target access network, > >[Ahmad] > (a) Maintaining QoS classification .... Ok. > >Comment No. 2: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This document specifies an extension to the PMIPv6 protocol, which > enables the transport of established QoS descriptions between an LMA > and the MAG by means of a QoS container option in case the QoS policy > in the WLAN access is not under explicit control of a policy control > system. > >[Ahmad] >It is not clear what you are trying to say in here. I am thinking the auth= ors >intention is to say that in case there is no out of bound policy control >mechanism, this document specifies an inbound mechanism using an extension >to the PMIPv6 protocol. May be this can be rephrased to capture the mentio= ned >meaning. Agreed. How about that (omitting the pointer to the policy control system): This document specifies an extension to the PMIPv6 protocol to establish Qo= S policies for an MN's data traffic on the LMA and the MAG. QoS policies are conveyed = in-band with PMIPv6 signaling using the specified QoS option and are enforced on the LMA= for downlink traffic and on the MAG for uplink traffic. > >Comment No. 3: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The specified option allows association between IP session > keys, such as a Differentiated Services Code Point (DSCP), and the > expected QoS class for this IP session. > >[Ahmad] >I have a problem with the word "keys", maybe we can say IP session >classification parameters, > I think your proposal is good. We'll adopt it. > > >Comment No. 4: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The MN is first connected to the LTE network and having a multimedia > session such as a video call with appropriate QoS parameters set by > the policy control function. > >[Ahmad] >All of a sudden introduced LTE network, maybe we can rephrase this as foll= ows: > > The MN is first connected to the cellular network, e.g., LTE network, a= nd >having a multimedia ...... Good point. > >Comment No. 5: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >3.3. Use Case B -- Establishment of new QoS Context in non-3G Access > >[Ahmad] >I guess the intention to say non-3GPP ? Yes. Even better: '..non-cellular Access'. Ok with you? > > >Comment No. 6: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >3.5. Relevant QoS Attributes > >[Ahmad] >Although, TFT is not considered a QoS parameter, but it is quite important= . I did >not see the UL TFT is mentioned anywhere. Is it handled outside this docum= ent? >If it is, we need to mention that because it tightly coupled with the enfo= rcement >of the QoS. The TFT is a cellular-specific concept, better a collection of filter and m= apping rules, that holds flow information and allow mapping of each flow to a bearer in t= he cellular network. The downlink TFT applies to the MAG in the cellular network which = use PMIP, the uplink TFT (do you refer only to this one?) applies to the MN. I consid= er functions of the TFT on both sides out of scope of this document's focus, as it's relate= d to bearer mapping. Also I do not think the spec needs to classify it explicitly as out of scop= e. Implementations may re-use the TFT data structures to hold and maintain QoS information for non-cellular access, but I'd hesitate entering that level a= nd the need to introduce a TFT term, which also needs to be described then. Other opinions? > >After reading on, there is Traffic Selector Attribute (section 4.1, etc). = However, >the following text is a little misleading and gives the impression as the = additional >attributes are out of scope. > > For some optional QoS attributes the signaling can differentiate > enforcement per mobility session and per IP flow. Additional > attributes can be appended to the QoS option, but their definition > and specification is out of scope of this document and left to their > actual deployment. > >I think the above text can be modified to clearly reference Traffic Select= or. Not sure I got your point correctly. The specification of additional QoS at= tributes and the associated options' format is out of scope of this specification, but m= ay be relevant for a particular deployment. Means, the specified mechanisms can be used to convey more options, e.g. ones that are defined by other SDOs. About the Traffic Selector, what else than a reference to RFC6088 would you like to see in the draft? > > >Technical Comments: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment No. 1: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Under section 4.2 " Local Mobility Anchor Considerations" , it says the fo= llowing: > > The flow selectors and the parameters for flow treatment MUST be > included in the option only if QoS policy is expected to apply at the > flow level. > >On the other hand, under section 5, "Quality of Service Option", it says t= he DSCP >value to be used for the flow: > > o DSCP: An 6-bit unsigned integer indicating the code point value, > as defined in [RFC2475] to be used for the flow. > >[Ahmad] >It is not clear to me how this will work out. If the DSCP is a fixed field= in the QoS >option, then how this will work to allow having different flows with diffe= rent >DSCP(s). Let me try to explain where I am lost! :-) > >If the mobility session was established for default kind of traffic and th= e QoS >DSCP was communicated for a QCI of 9 (DSCP1) for example. Then at a later >time, the MN establishes some application session (flow) with QCI 1 and th= e >returned QoS has a DSCP (DSCP2) in the fixed field and probably a Traffic >Selector since it is a per single flow. > >Now: when the MAG receives the new PBA, is DSCP2 for this flow only and th= e >old DSCP1 for every other traffic? How that should work in relation with t= he >above DSCP field definition? Per-flow policies overrule default policies. I hope this is only a clarific= ation issue in the draft, or do you see an inconsistency and technical issue here? > > >Comment No. 2: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Under section 6, the Guaranteed Downlink Bit Rate is missing. Only in the listed attributes, not in the specification (Sec. 6.6 and 6.7). Thanks for the catch!=20 > > > >Comment No. 3: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Under section 6.8, "Traffic Selector", it says the following: > > MUST be included if QoS parameters (Options according to Section 6.5 > to Section 6.7) are expected to apply at the flow level > >[Ahmad] >Why did you single out these two sections only? Because the use of per-flow rules made sense here, whereas the per-Mobility Session attributes should represent an aggregated view taking all flows of the mobility session into account. >For example, section 6.5, says the following: > >" >6.5. Allocation and Retention Priority > > ....... > If the attribute is expected to apply at the flow level, the > traffic selector (Section 6.8) MUST be included in the QoS option. >" > >I suggest modifying the text as follows: > > MUST be included when QoS is expected to be applied at the flow level. Ok. > > >Comment No. 4: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Since the Guaranteed Downlink Bit Rate is missing, please recheck the assi= gned >type values and their order in section 6 and the following subsections. Al= so, >please update the IANA section accordingly. Ok. Thanks again for your detailed comments and suggestions. marco > > >Regards, >Ahmad > > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >+++++++++++++++++++++ >From: Basavaraj Patil [mailto:bpatil1@gmail.com] >Sent: Tuesday, May 14, 2013 4:37 PM >To: Ahmad Muhanna >Cc: netext@ietf.org >Subject: Request for review of I-D: draft-ietf-netext-pmip6-qos-02 > > >Hi Ahmad, > >We would appreciate it if you can review the I-D:=A0uality of Service Opti= on for >Proxy Mobile IPv6 . > >Please post your review comments directly to the list. If you can complete= the >review within the next 2 weeks, that would be much appreciated. > >Thank you. > >-Chairs > >-- >Basavaraj Patil >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From internet-drafts@ietf.org Mon Jun 17 10:43:05 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6135021F9D74; Mon, 17 Jun 2013 10:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoWfQTsUPiJH; Mon, 17 Jun 2013 10:43:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB87C21F9D15; Mon, 17 Jun 2013 10:43:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130617174304.17353.6727.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 10:43:04 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:43:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Update Notifications for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Sri Gundavelli Marco Liebsch Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-netext-update-notifications-05.txt Pages : 18 Date : 2013-06-17 Abstract: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-update-notifications-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jun 18 09:54:39 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883EA21F9B01; Tue, 18 Jun 2013 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUJgDowsBfhr; Tue, 18 Jun 2013 09:54:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FD211E80DF; Tue, 18 Jun 2013 09:54:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130618165433.13710.84861.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 09:54:33 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:54:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-09.txt Pages : 27 Date : 2013-06-18 Abstract: This specification defines extensions to Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain delegated IP prefixes for its attached mobile networks. The mobility entities in the network will provide network-based mobility management support for those delegated IP prefixes just as how IP mobility support is provided for the mobile node's home address. Even as the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexandru.petrescu@gmail.com Thu Jun 20 06:45:25 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D279721F9CB3 for ; Thu, 20 Jun 2013 06:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.414 X-Spam-Level: X-Spam-Status: No, score=-9.414 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYG-OGjD5Ha7 for ; Thu, 20 Jun 2013 06:45:18 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9130921F9CA0 for ; Thu, 20 Jun 2013 06:45:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5KDjEJN001055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Jun 2013 15:45:14 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5KDjEpH016951 for ; Thu, 20 Jun 2013 15:45:14 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5KDj8Qf022010 for ; Thu, 20 Jun 2013 15:45:14 +0200 Message-ID: <51C30764.1010709@gmail.com> Date: Thu, 20 Jun 2013 15:45:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 CC: netext@ietf.org References: <20130618165433.13710.84861.idtracker@ietfa.amsl.com> In-Reply-To: <20130618165433.13710.84861.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:45:26 -0000 Hello, The functionality offered to the Mobile Router, as described in this draft, is similar if not the same as what the 64share draft does draft-ietf-v6ops-64share-07 behaviour called 'IPv6 tethering' and witnessed on smartphones on cellular operators. A deployer of Mobile Routers faces thus two alternatives: should use 64share exclusively on the smartphone? Or should deploy PMIP-PD in the infrastructure? It's pointless to do both. Remark also that 64share v6ops discussion seems to have an oppinion with respect to DHCPv6-PD (it is the right thing to do), yet no oppinion about PMIP-PD. Given these aspects, I am surprised there is no reference from one draft to the other. Alex Le 18/06/2013 18:54, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network-Based Mobility > Extensions Working Group of the IETF. > > Title : Prefix Delegation Support for Proxy Mobile IPv6 > Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri > Gundavelli Carlos J. Bernardos Filename : > draft-ietf-netext-pd-pmip-09.txt Pages : 27 Date > : 2013-06-18 > > Abstract: This specification defines extensions to Proxy Mobile IPv6 > protocol for allowing a mobile router in a Proxy Mobile IPv6 domain > to obtain delegated IP prefixes for its attached mobile networks. > The mobility entities in the network will provide network-based > mobility management support for those delegated IP prefixes just as > how IP mobility support is provided for the mobile node's home > address. Even as the mobile router performs a handoff and changes its > network point of attachment, mobility support is ensured for all the > delegated IP prefixes and for all the IP nodes in the mobile network > that use IP address configuration from those delegated IP prefixes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pd-pmip-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ netext mailing list > netext@ietf.org https://www.ietf.org/mailman/listinfo/netext > > From jouni.nospam@gmail.com Fri Jun 21 01:39:39 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3AF21E80CB for ; Fri, 21 Jun 2013 01:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moPdROA5obmX for ; Fri, 21 Jun 2013 01:39:39 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0011E810C for ; Fri, 21 Jun 2013 01:39:38 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id z7so4411694eaf.6 for ; Fri, 21 Jun 2013 01:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YKGLGX3id7ax5cBbCVGkVROiRu3ShaEpN55MPuu+eYk=; b=bSddH7xgthgMop8BR5tigggkAzSHtGeQJtgGLGJ/rqVUQRgBhxeUQ0igE51yEuJHW0 KKdxDov6lC7h9lfQBdNVCPy4GMIuvIxbbx0czt1KKIy3SGoVwsFzL/xG8waGjJElDdKh Qtq8HzGOySkJZIas18oQ0Etg+omv2+vzHcAzUojUcPXITQeqcn18Bec7BPm18+CluJ/a EvoGb8apoadGuYxnYc9oxmgNAwJVSu4YLPjAtgVmuR9oDZ7DTMYWp1MHXyJFbqPt+3hU E3b5b8i/0zPdCzGAfo/BIa20rbvl7zUVPmuh6jBDTEjYU7Ub4qZm1Mz5JBxlyIPugEgc k8/g== X-Received: by 10.14.173.70 with SMTP id u46mr11333301eel.92.1371803977383; Fri, 21 Jun 2013 01:39:37 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id e44sm6045040eeh.11.2013.06.21.01.39.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 01:39:35 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <51C30764.1010709@gmail.com> Date: Fri, 21 Jun 2013 11:39:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <80BDC091-5C17-4299-B310-298093A21E6F@gmail.com> References: <20130618165433.13710.84861.idtracker@ietfa.amsl.com> <51C30764.1010709@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1508) Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:39:39 -0000 On Jun 20, 2013, at 4:45 PM, Alexandru Petrescu = wrote: > Hello, >=20 > The functionality offered to the Mobile Router, as described in this > draft, is similar if not the same as what the 64share draft does > draft-ietf-v6ops-64share-07 behaviour called 'IPv6 tethering' and > witnessed on smartphones on cellular operators. Obviously we are and were aware of this all the time.. > A deployer of Mobile Routers faces thus two alternatives: should use > 64share exclusively on the smartphone? Or should deploy PMIP-PD in = the > infrastructure? It's pointless to do both. You are missing one thing here. What NETEXT is doing is specific to PMIPv6 and fixes/clarifies a specific issue related to prefix = delegation. >=20 > Remark also that 64share v6ops discussion seems to have an oppinion = with > respect to DHCPv6-PD (it is the right thing to do), yet no oppinion > about PMIP-PD. >=20 > Given these aspects, I am surprised there is no reference from one = draft > to the other. Because there is no need. The v6ops work is independent of what NETEXT = is doing and what NETEXT is doing cannot prohibit an operator deploying = what v6ops is defining.. - Jouni >=20 > Alex >=20 > Le 18/06/2013 18:54, internet-drafts@ietf.org a =E9crit : >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Network-Based Mobility >> Extensions Working Group of the IETF. >>=20 >> Title : Prefix Delegation Support for Proxy Mobile IPv6 >> Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri >> Gundavelli Carlos J. Bernardos Filename : >> draft-ietf-netext-pd-pmip-09.txt Pages : 27 Date >> : 2013-06-18 >>=20 >> Abstract: This specification defines extensions to Proxy Mobile IPv6 >> protocol for allowing a mobile router in a Proxy Mobile IPv6 domain >> to obtain delegated IP prefixes for its attached mobile networks. >> The mobility entities in the network will provide network-based >> mobility management support for those delegated IP prefixes just as >> how IP mobility support is provided for the mobile node's home >> address. Even as the mobile router performs a handoff and changes its >> network point of attachment, mobility support is ensured for all the >> delegated IP prefixes and for all the IP nodes in the mobile network >> that use IP address configuration from those delegated IP prefixes. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-09 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-09 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ netext mailing list >> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext >>=20 >>=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From alexandru.petrescu@gmail.com Fri Jun 21 10:23:36 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A723121F9FCB for ; Fri, 21 Jun 2013 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGMkm8vdxDq6 for ; Fri, 21 Jun 2013 10:23:31 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7517D21F9FE6 for ; Fri, 21 Jun 2013 10:23:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5LHNSl6023095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 19:23:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5LHNSIa018407; Fri, 21 Jun 2013 19:23:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5LHNRkK018427; Fri, 21 Jun 2013 19:23:28 +0200 Message-ID: <51C48C0F.1070804@gmail.com> Date: Fri, 21 Jun 2013 19:23:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jouni Korhonen References: <20130618165433.13710.84861.idtracker@ietfa.amsl.com> <51C30764.1010709@gmail.com> <80BDC091-5C17-4299-B310-298093A21E6F@gmail.com> In-Reply-To: <80BDC091-5C17-4299-B310-298093A21E6F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-pd-pmip-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:23:37 -0000 Le 21/06/2013 10:39, Jouni Korhonen a écrit : > > On Jun 20, 2013, at 4:45 PM, Alexandru Petrescu wrote: > >> Hello, >> >> The functionality offered to the Mobile Router, as described in this >> draft, is similar if not the same as what the 64share draft does >> draft-ietf-v6ops-64share-07 behaviour called 'IPv6 tethering' and >> witnessed on smartphones on cellular operators. > > Obviously we are and were aware of this all the time.. That is good. But also obviously if one is done the other is not needed. >> A deployer of Mobile Routers faces thus two alternatives: should use >> 64share exclusively on the smartphone? Or should deploy PMIP-PD in the >> infrastructure? It's pointless to do both. > > You are missing one thing here. What NETEXT is doing is specific to > PMIPv6 and fixes/clarifies a specific issue related to prefix delegation. I thought both were specific to IPv6. >> Remark also that 64share v6ops discussion seems to have an oppinion with >> respect to DHCPv6-PD (it is the right thing to do), yet no oppinion >> about PMIP-PD. >> >> Given these aspects, I am surprised there is no reference from one draft >> to the other. > > Because there is no need. The v6ops work is independent of what NETEXT is > doing and what NETEXT is doing cannot prohibit an operator deploying what > v6ops is defining.. I am not going then to ask why NETEXT is doing what is doing, neither v6ops. But it is surprising these two alternatives realize the same functionality. Whether you want to agree to this or not is another matter :-) Alex > > - Jouni > >> >> Alex >> >> Le 18/06/2013 18:54, internet-drafts@ietf.org a écrit : >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Network-Based Mobility >>> Extensions Working Group of the IETF. >>> >>> Title : Prefix Delegation Support for Proxy Mobile IPv6 >>> Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri >>> Gundavelli Carlos J. Bernardos Filename : >>> draft-ietf-netext-pd-pmip-09.txt Pages : 27 Date >>> : 2013-06-18 >>> >>> Abstract: This specification defines extensions to Proxy Mobile IPv6 >>> protocol for allowing a mobile router in a Proxy Mobile IPv6 domain >>> to obtain delegated IP prefixes for its attached mobile networks. >>> The mobility entities in the network will provide network-based >>> mobility management support for those delegated IP prefixes just as >>> how IP mobility support is provided for the mobile node's home >>> address. Even as the mobile router performs a handoff and changes its >>> network point of attachment, mobility support is ensured for all the >>> delegated IP prefixes and for all the IP nodes in the mobile network >>> that use IP address configuration from those delegated IP prefixes. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-09 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pd-pmip-09 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ netext mailing list >>> netext@ietf.org https://www.ietf.org/mailman/listinfo/netext >>> >>> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > > From amuhanna@awardsolutions.com Tue Jun 25 07:51:22 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B9F21E80FB for ; Tue, 25 Jun 2013 07:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmMQFAAf7hWN for ; Tue, 25 Jun 2013 07:51:13 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with ESMTP id DE3FC21E8098 for ; Tue, 25 Jun 2013 07:51:11 -0700 (PDT) Received: from mail.awardsolutions.com ([66.142.250.98]) (using TLSv1) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKUcmuVbXW4M7XyhAjE7RiBijakzNsJoyn@postini.com; Tue, 25 Jun 2013 07:51:12 PDT Received: from REDWOOD.usa.awardsolutions.com ([fe80::6d1b:ab4f:9248:e8a3]) by Redwood.usa.awardsolutions.com ([fe80::6d1b:ab4f:9248:e8a3%11]) with mapi id 14.01.0438.000; Tue, 25 Jun 2013 09:51:00 -0500 From: Ahmad Muhanna To: Marco Liebsch , "netext@ietf.org" Thread-Topic: Review Comments on: draft-ietf-netext-pmip6-qos-02 Thread-Index: AQHOX8ZdB+OpDwjqFUavB5log0rF05k6egmAgAwkusA= Date: Tue, 25 Jun 2013 14:50:59 +0000 Message-ID: <3359F724933DFD458579D24EAC769098A217AB7F@Redwood.usa.awardsolutions.com> References: <3359F724933DFD458579D24EAC7690988B231081@Redwood.usa.awardsolutions.com> <69756203DDDDE64E987BC4F70B71A26D552CD2D7@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D552CD2D7@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.208.163] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Basavaraj Patil Subject: Re: [netext] Review Comments on: draft-ietf-netext-pmip6-qos-02 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:51:25 -0000 Hi Marco, Sorry I was out last week. I would like to address your comments as follows. The below is in general a= nd comments to your specific replies. In general, I agree 3GPP standard does not specify a PMIPv6 tunnel that is = comparable to a GTP bearer. That's given. However, that is the reason 3GPP = specify a different PCC architecture when PMIP is used. In other words, the= MAG goes directly to the PCRF over Gxa, for example. I believe that allowing a different architecture for PCC to be used over PM= IP6 must have one of two options. 1. Define the needed extras for PMIP6 to be able to be comparable to GTP be= arer and then use PCC as it is being used for GTP and as you are trying to = use in your draft, this means you need to describe the scenarios to the lev= el of bearers and NOT MN or Mobility session. However, I must say that this= option SHOULD NOT be addressed in IETF and should be handled in 3GPP stand= ardization, for example SA2. I remember in the past there was lots of discu= ssion related to PCC architecture and for PMIP the option was to use out-of= -bound mechanism. 2. Forget about 3GPP PCC and define your own mechanism for exchanging some = QoS parameters without ANY reference to 3GPP. That is possible but I am not= sure about the value. Having said the above, please see more responses below. Best Regards, Ahmad -----Original Message----- From: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu]=20 Sent: Monday, June 17, 2013 10:54 AM To: Ahmad Muhanna; netext@ietf.org Cc: Basavaraj Patil Subject: RE: Review Comments on: draft-ietf-netext-pmip6-qos-02 Hi Ahmad, thanks a lot for your detailed comments and proposals. Please see inline for feedback. >-----Original Message----- >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On=20 >Behalf Of Ahmad Muhanna >Sent: Sonntag, 2. Juni 2013 21:21 >To: netext@ietf.org >Cc: Basavaraj Patil >Subject: [netext] Review Comments on: draft-ietf-netext-pmip6-qos-02 > >Hi Raj and authors, > >I have reviewed this draft and I have the below comments. > >General Comment: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >I have found it difficult to follow this document differentiation=20 >between IP session, IP flows, Mobility Session with respect to QoS.=20 >Since this document reference 3GPP specification for the purpose of=20 >QoS, we realize that QoS (in >3GPP) is enforced at the level of a bearer. Thus, when we talk about IP=20 >session, is that a single bearer or all types of traffic/flows is carried = over this IP session. >May be the question is: what is the equivalent of a bearer in PMIPv6?=20 >Then we should make sure that we use that definition when referring to=20 >QoS enforcement. I would not try to map the bearer concept, which applies to cellular networ= ks, to IP tunneling as used by PMIP. A PMIP tunnel is shared even by multip= le users, whereas the bearer is established per MN and per QoS. I'd rather = add more text about how QoS differentiation should be enabled on a PMIP tun= nel. In current cellular systems, mapping of flows to a per MN and per-QoS = bearer is performed on the downlink after the termination of the PMIP tunne= l, i.e. at the MAG. So, no bearer assumed on PMIP even in cellular networks= . Scope of the spec is to enable QoS differentiation by means of DSCPs on t= he PMIP tunnel and opt for mapping of QoS rules to non-cellular access tech= nology specific QoS. [Ahmad:]=20 [Ahmad:] Please see my comments above. > >After reading on, section 4.1., mentions that the QoS is applied at=20 >three different levels, IP flow, Mobility Session, or per MN. >May be it is a good idea to have this mentioned upfront in the=20 >introduction section in order to set the stage correctly. In addition=20 >somehow, this document needs to provide the detailed logic to differentiat= e between the three cases. Fully agree to that point and we addressed past comments on this mainly in = the message format description. The general parts, such as the Intro, lack = in clear text, which we'll add in the updated version. Thanks again for the= hint. [Ahmad:] Thank you. > > >Editorial: >Comment No. 1: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > (a) Maintenance of QoS classification during a handover between > cellular radio access and WLAN access by means of establishing QoS > policies in the handover target access network, > >[Ahmad] > (a) Maintaining QoS classification .... Ok. > >Comment No. 2: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This document specifies an extension to the PMIPv6 protocol, which > enables the transport of established QoS descriptions between an LMA > and the MAG by means of a QoS container option in case the QoS policy > in the WLAN access is not under explicit control of a policy control > system. > >[Ahmad] >It is not clear what you are trying to say in here. I am thinking the=20 >authors intention is to say that in case there is no out of bound=20 >policy control mechanism, this document specifies an inbound mechanism=20 >using an extension to the PMIPv6 protocol. May be this can be rephrased=20 >to capture the mentioned meaning. Agreed. How about that (omitting the pointer to the policy control system): This document specifies an extension to the PMIPv6 protocol to establish Qo= S policies for an MN's data traffic on the LMA and the MAG. QoS policies ar= e conveyed in-band with PMIPv6 signaling using the specified QoS option and are enforced on the LMA= for downlink traffic and on the MAG for uplink traffic. [Ahmad:]=20 I think that may be an option as I listed above. However, you need to prese= nt this document as a mechanism for exchanging some QoS parameters that you= need to define in this document or reference other IETF documents because = you no longer is able to reference any 3GPP documents. In that case, please= make sure that the document is consistent across the board and I believe t= he new/updated document needs further fresh reviews. > >Comment No. 3: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The specified option allows association between IP session > keys, such as a Differentiated Services Code Point (DSCP), and the > expected QoS class for this IP session. > >[Ahmad] >I have a problem with the word "keys", maybe we can say IP session=20 >classification parameters, > I think your proposal is good. We'll adopt it. > > >Comment No. 4: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The MN is first connected to the LTE network and having a multimedia > session such as a video call with appropriate QoS parameters set by > the policy control function. > >[Ahmad] >All of a sudden introduced LTE network, maybe we can rephrase this as foll= ows: > > The MN is first connected to the cellular network, e.g., LTE=20 >network, and having a multimedia ...... Good point. > >Comment No. 5: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >3.3. Use Case B -- Establishment of new QoS Context in non-3G Access > >[Ahmad] >I guess the intention to say non-3GPP ? Yes. Even better: '..non-cellular Access'. Ok with you? [Ahmad:] Yes. If you agree to not reference 3GPP standardization, this come= s natural. Thanks! > > >Comment No. 6: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >3.5. Relevant QoS Attributes > >[Ahmad] >Although, TFT is not considered a QoS parameter, but it is quite=20 >important. I did not see the UL TFT is mentioned anywhere. Is it handled o= utside this document? >If it is, we need to mention that because it tightly coupled with the=20 >enforcement of the QoS. The TFT is a cellular-specific concept, better a collection of filter and m= apping rules, that holds flow information and allow mapping of each flow to= a bearer in the cellular network. The downlink TFT applies to the MAG in t= he cellular network which use PMIP, the uplink TFT (do you refer only to th= is one?) applies to the MN. I consider functions of the TFT on both sides o= ut of scope of this document's focus, as it's related to bearer mapping. =20 [Ahmad:] May be I am missing something here. At the end regardless of the m= apping to a single bearer or a tunnel for multiple UEs, you need to enforce= the PCC rules at the level of flows. That could be a wild card but if you = have a solution that assumes wild card all the time, then you may have a pr= oblem. In other words, I believe the TFT is needed to be communicated to th= e UE and the MAG. If in non-cellular the UE does not need to have the uplin= k TFT, then please explain this in the draft. In other words, whatever opti= on you want to choose, please mention the justification. Thanks. Also I do not think the spec needs to classify it explicitly as out of scop= e. Implementations may re-use the TFT data structures to hold and maintain QoS= information for non-cellular access, but I'd hesitate entering that level = and the need to introduce a TFT term, which also needs to be described then= . Other opinions? [Ahmad:] Well, then we disagree. That communication of QoS parameters is us= eless if you do not know how to enforce it. Whenever, people talks about PC= C, they automatically thinks of the enforcement and you need to address it.= Either referencing other IETF documents or give justification for why it i= s not needed. > >After reading on, there is Traffic Selector Attribute (section 4.1,=20 >etc). However, the following text is a little misleading and gives the=20 >impression as the additional attributes are out of scope. > > For some optional QoS attributes the signaling can differentiate > enforcement per mobility session and per IP flow. Additional > attributes can be appended to the QoS option, but their definition > and specification is out of scope of this document and left to their > actual deployment. > >I think the above text can be modified to clearly reference Traffic Select= or. Not sure I got your point correctly. The specification of additional QoS at= tributes and the associated options' format is out of scope of this specifi= cation, but may be relevant for a particular deployment. Means, the specifi= ed mechanisms can be used to convey more options, e.g. ones that are define= d by other SDOs. [Ahmad:] That should be fine. About the Traffic Selector, what else than a reference to RFC6088 would you= like to see in the draft? [Ahmad:] That should suffice to eliminate the possible misunderstanding of = the text above. > > >Technical Comments: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Comment No. 1: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Under section 4.2 " Local Mobility Anchor Considerations" , it says the fo= llowing: > > The flow selectors and the parameters for flow treatment MUST be > included in the option only if QoS policy is expected to apply at the > flow level. > >On the other hand, under section 5, "Quality of Service Option", it=20 >says the DSCP value to be used for the flow: > > o DSCP: An 6-bit unsigned integer indicating the code point value, > as defined in [RFC2475] to be used for the flow. > >[Ahmad] >It is not clear to me how this will work out. If the DSCP is a fixed=20 >field in the QoS option, then how this will work to allow having=20 >different flows with different DSCP(s). Let me try to explain where I=20 >am lost! :-) > >If the mobility session was established for default kind of traffic and=20 >the QoS DSCP was communicated for a QCI of 9 (DSCP1) for example. Then=20 >at a later time, the MN establishes some application session (flow)=20 >with QCI 1 and the returned QoS has a DSCP (DSCP2) in the fixed field=20 >and probably a Traffic Selector since it is a per single flow. > >Now: when the MAG receives the new PBA, is DSCP2 for this flow only and=20 >the old DSCP1 for every other traffic? How that should work in relation=20 >with the above DSCP field definition? Per-flow policies overrule default policies. I hope this is only a clarific= ation issue in the draft, or do you see an inconsistency and technical issu= e here? [Ahmad:]=20 As I said earlier, please remember you are defining a new mechanism for usi= ng 3GPP PCC architecture that is NOT defined by 3GPP. May be if you agree o= n the previous comments above, then this point will automatically be addres= sed. > > >Comment No. 2: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Under section 6, the Guaranteed Downlink Bit Rate is missing. Only in the listed attributes, not in the specification (Sec. 6.6 and 6.7). Thanks for the catch!=20 > > > >Comment No. 3: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Under section 6.8, "Traffic Selector", it says the following: > > MUST be included if QoS parameters (Options according to Section 6.5 > to Section 6.7) are expected to apply at the flow level > >[Ahmad] >Why did you single out these two sections only? Because the use of per-flow rules made sense here, whereas the per-Mobility= Session attributes should represent an aggregated view taking all flows of= the mobility session into account. [Ahmad:]=20 May be the new approach (if you agree on the above comments) will address t= his too. >For example, section 6.5, says the following: > >" >6.5. Allocation and Retention Priority > > ....... > If the attribute is expected to apply at the flow level, the > traffic selector (Section 6.8) MUST be included in the QoS option. >" > >I suggest modifying the text as follows: > > MUST be included when QoS is expected to be applied at the flow level. Ok. > > >Comment No. 4: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Since the Guaranteed Downlink Bit Rate is missing, please recheck the=20 >assigned type values and their order in section 6 and the following=20 >subsections. Also, please update the IANA section accordingly. Ok. Thanks again for your detailed comments and suggestions. Marco [Ahmad:]=20 Thanks Marco! > > >Regards, >Ahmad > > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >+++++++++++++++++++++ >From: Basavaraj Patil [mailto:bpatil1@gmail.com] >Sent: Tuesday, May 14, 2013 4:37 PM >To: Ahmad Muhanna >Cc: netext@ietf.org >Subject: Request for review of I-D: draft-ietf-netext-pmip6-qos-02 > > >Hi Ahmad, > >We would appreciate it if you can review the I-D:=A0uality of Service=20 >Option for Proxy Mobile IPv6 . > >Please post your review comments directly to the list. If you can=20 >complete the review within the next 2 weeks, that would be much appreciate= d. > >Thank you. > >-Chairs > >-- >Basavaraj Patil >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext