idnits 2.17.1 draft-wang-netext-trace-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5213]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Wang 2 Internet Draft Q.Wu 3 Huawei 4 Intended status: Standards Track July 6, 2009 5 Expires: January 2010 7 Trace Control Support for Proxy Mobile IPv6 8 draft-wang-netext-trace-control-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on January 6, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 In some Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments, a mobility 46 session needs to be traced by the back-end network manager for 47 network diagnosis, troubleshooting, new service testing, etc. This 48 document defines a Trace Session option for PMIPv6 protocol to 49 control and manage (activation and de-activation) a trace session 50 associated with a mobility session of the mobile node. This option is 51 sent by the mobile access gateway in Proxy Binding Update message to 52 request the local mobile anchor to activate the trace session. When 53 the local mobile anchor successfully processes the Proxy Binding 54 Update, it then activates the trace session and starts to 55 record/report the traced mobility session based on the corresponding 56 trace parameters. 58 Table of Contents 60 1. Introduction.................................................3 61 2. Conventions used in this document............................3 62 3. Protocol Overview............................................3 63 4. Mobile Access Gateway Considerations.........................4 64 4.1. Extensions to the Conceptual Data Structure.............4 65 4.2. Signaling Consideration.................................4 66 5. Local Mobile Anchor Consideration............................5 67 5.1. Extensions to the Conceptual Data Structure.............5 68 5.2. Signaling Consideration.................................5 69 6. Message Format...............................................6 70 6.1. Trace Session option....................................6 71 7. Security Considerations......................................7 72 8. IANA Considerations..........................................7 73 9. References...................................................7 74 9.1. Normative References....................................7 75 9.2. Informative References..................................7 76 10. Acknowledgments.............................................7 78 1. Introduction 80 In some Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments, a mobility 81 session of the mobile node needs to be traced by the back-end network 82 manager for network diagnosis, troubleshooting, new service testing, 83 etc. If a mobility session of the mobile node is being traced, the 84 MAG and the LMA should firstly activate trace session associated with 85 the mobility session of the mobile node respectively and then start 86 to record/report the traced mobility session based on the 87 corresponding trace parameters to the back-end network manager. In 88 this case, the trace session is used to configure trace parameters 89 and identify the time interval through activation and de-activation 90 operations. In order to synchronize starting trace session between 91 the MAG and the LMA, the interaction between the MAG and the LMA is 92 required. However there is no relevant works to discuss how the trace 93 session is propagated from the mobile access gateway to the local 94 mobile anchor. 96 This document defines a new mobility option, i.e., trace session 97 option. This option is used by the MAG to carry trace parameter to 98 the LMA and activate the trace session associate with the mobility 99 session of the mobile node. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC2119 [RFC2119]. 107 3. Protocol Overview 109 This document defines a new extension for PMIPv6 protocol to control 110 and manage (activation and de-activation) a trace session associated 111 with a special mobility session of the mobile node by using the Trace 112 Session option. 114 When the mobile node is attached to the mobile access gateway, the 115 AAA server propagates the trace parameters to the mobile access 116 gateway after the mobile node is successfully authenticated and 117 authorized. And then the MAG stores the trace parameters in the 118 mobile node's binding cache entry and activates the trace session. 120 The mobile access gateway further propagates the trace parameters 121 encapsulated into the Trace Session option in the Proxy Binding 122 Update message to the mobile node's local mobile anchor. When the 123 local mobility anchor successfully processes the Proxy Binding Update 124 message, it then stores the trace parameters in the mobile node's 125 binding cache entry and activates the trace session. 127 4. Mobile Access Gateway Considerations 129 4.1. Extensions to the Conceptual Data Structure 131 The binding update list (defined in section 6.1 of [RFC5213]) 132 maintained on the mobile access gateway should be extended with 133 following additional fields in this document. 135 O Session Identifier, the identifier of the trace session. This 136 identifier is used to identify a unique trace session of a mobile 137 node and can be acquired when the trace session is activated. 139 O Trace Parameters, the parameters of the trace session. These 140 parameters are acquired when the trace session is activated and 141 are used to determine what and when the mobility session of the 142 mobile node is recorded and reported, etc. 144 4.2. Signaling Consideration 146 O If the mobile access gateway determines that a mobility session 147 of a mobile node needs to be traced, it sends a Proxy Binding 148 Update message with the Trace Session option to the local 149 mobility anchor. In the Trace Session option, following 150 parameters should be set. 152 - The session identifier of the trace session to be activated. 153 It is assigned by the mobile access gateway or acquired from 154 policy server. 156 - The A-flag is set to 1. 158 - Trace parameters the trace session to be activated. They are 159 acquired from policy server. 161 O If the mobile access gateway determines that a trace session of a 162 mobile node needs to be stopped, it sends a Proxy Binding Update 163 message with the Trace Session option to the local mobility 164 anchor. In the Trace Session option, following parameters should 165 be set. 167 - The session identifier of the trace session to be de-activated. 169 - A-flag is set to 0. 171 5. Local Mobile Anchor Consideration 173 5.1. Extensions to the Conceptual Data Structure 175 The binding update list (defined in section 5.1 of [RFC5213]) 176 maintained on the local mobile anchor should be extended with 177 following additional fields in this document. 179 O Session Identifier, the identifier of the trace session. This 180 identifier is used to identify a unique trace session of a mobile 181 node and can be acquired when the trace session is activated and 183 O Trace Parameters, the parameters of the trace session. These 184 parameters are acquired when the trace session is activated and 185 are used to determine what and when the mobility session of the 186 mobile node is recorded and reported, etc. 188 5.2. Signaling Consideration 190 If the local mobility anchor successfully processes a Proxy Binding 191 Update message with the Trace Session option, it must perform the 192 following actions. 194 O If the A-flag is set to 1 and the session identifier is firstly 195 presented, the local mobile anchor MUST store the session 196 identifier and trace parameters in the corresponding BCE and 197 activate the trace session of the mobility session. 199 O If the A-flag is set to 1 and the session identifier is re- 200 presented (matching the session identifier in the corresponding 201 BCE), the local mobile anchor MUST update trace parameters in the 202 corresponding BCE and re-activate the trace session of the 203 mobility session. 205 O If the A-flag is set to 0 and the session identifier matches an 206 existing session identifier of the trace session, the local 207 mobile anchor MUST stop the trace session of the mobility session 208 and delete the session identifier and the trace parameters of the 209 trace session. 211 O If the A-flag is set to 0 and the session identifier matches an 212 existing session identifier of the trace session, the local 213 mobile anchor MUST stop the trace session of the mobility session 214 and delete the session identifier and the trace parameters of the 215 trace session. 217 After the Proxy Binding Update message is successfully processed, the 218 local mobility anchor MUST respond with a successful Proxy Binding 219 Acknowledgement with the Trace Session option. The option is only 220 included with the A-flag and the session identifier which are set 221 with the same values in the corresponding Trace Session option of the 222 Proxy Binding Update message. 224 6. Message Format 226 6.1. Trace Session option 228 The Trace Session option contains a unique session identifier, a flag 229 to indicate activation or de-activation of a trace session and the 230 trace parameters which are configured on the MAG and the LMA to 231 indication start and stop of recording the traced mobility session 232 and further reporting the record information to the back-end server. 234 The format of the option is: 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Length | Session Id |A| Reserved | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Trace Parameters ... 242 +-+-+-+-+-+-+-+-+-+-+-+-+ 244 Type 246 248 Length 250 8-bit unsigned integer, indicating the length in octets of the 251 option excluding the type and length fields. 253 Session Identifier 255 8-bit unsigned integer, the session identifier is unique for 256 each mobility session. One mobile node may have one or more 257 than one session identifiers. 259 A Flag 261 This flag indicates that the trace session of the mobile node 262 mobility session needs to be activated. When this flag is 263 cleared, it means the trace session of the mobile node mobility 264 session is requested to be de-activated. 266 Reserved 268 These fields are unused. They MUST be initialized to zero by 269 the sender and MUST be ignored by the receiver. 271 Trace Parameters 273 This field is variable length field. These parameters indicate 274 the detailed content of the trace session, which is defined out 275 of scope of this document. 277 7. Security Considerations 279 TBD 281 8. IANA Considerations 283 Trace Session option-type 285 9. References 287 9.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 293 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 295 9.2. Informative References 297 10. Acknowledgments 299 Thanks to Netext members for their comments. 301 Authors' Addresses 303 Yungui Wang 304 Huawei Technologies Co.,Ltd. 305 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 306 Nanjing, Jiangsu, 210001 P.R.China 308 Email: w52006@huawei.com 310 Qin Wu 311 Huawei Technologies Co.,Ltd. 312 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 313 Nanjing, Jiangsu, 210001 P.R.China 315 Email: sunseawq@huawei.com