idnits 2.17.00 (12 Aug 2021) /tmp/idnits38085/draft-fu-rsvp-multicast-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2002) is 7150 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2362 (ref. '4') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: draft-ietf-nsis-req has been published as RFC 3726 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '7') == Outdated reference: draft-ietf-nsis-fw has been published as RFC 4080 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '8') == Outdated reference: draft-ietf-ssm-overview has been published as RFC 3569 ** Downref: Normative reference to an Informational draft: draft-ietf-ssm-overview (ref. '9') == Outdated reference: A later version (-01) exists of draft-braden-2level-signal-arch-00 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-01) exists of draft-schulzrinne-nsis-casp-00 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-04) exists of draft-manner-lrsvp-00 -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft University of Goettingen 4 Expires: April 16, 2003 C. Kappler 5 H. Tschofenig 6 Siemens AG 7 October 16, 2002 9 Analysis on RSVP Regarding Multicast 10 draft-fu-rsvp-multicast-analysis-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 16, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 RSVP version 1 has been designed for optimum support multicast. 42 However, in reality multicast is being used much less frequently than 43 anticipated. Still, even for unicast (one sender, one receiver) 44 full-fledged multicast-enabled RSVP signaling must be used. As 45 pointed out in the NSIS requirement draft, multicast would not be 46 necessarily required for an NSIS signaling protocol. This draft 47 analyses ingredients of RSVP Version 1 which are affected by 48 multicast, and derives how these ingredients may look like if 49 multicast is not supported in the generic RSVP signaling protocol and 50 adapt related functionalities accordingly - we call the resulting 51 feature set "RSVP Lite", a potentially more light-weight version of 52 RSVP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Multicast-Influenced Ingredients in RSVP . . . . . . . . . . . 4 58 2.1 Reservation Styles and Scope Object . . . . . . . . . . . . . 4 59 2.2 Limitation on Receiver-Initiated Reservation . . . . . . . . . 4 60 2.3 Coupled QoS Specification with the Generic Signaling 61 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4 Complex State Merging Operation in the Routers for 63 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.5 Killer Problems and Error/Failure Handling . . . . . . . . . . 5 65 3. Towards a Light-weight RSVP: RSVP Lite . . . . . . . . . . . . 6 66 3.1 No Reservation Styles and Scope Object . . . . . . . . . . . . 6 67 3.2 Decoupling Signaled Data from Signaling . . . . . . . . . . . 6 68 3.3 No Restriction on Sender- or Receiver-Initiation . . . . . . . 6 69 3.4 Simpler State Management in Routers . . . . . . . . . . . . . 7 70 3.5 Simplified Error Handling . . . . . . . . . . . . . . . . . . 7 71 3.6 Message Types . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.7 Mobility Consideration . . . . . . . . . . . . . . . . . . . . 8 73 3.8 Multicast Consideration . . . . . . . . . . . . . . . . . . . 8 74 3.9 Potential Advantages of RSVP Lite . . . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 77 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 79 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 As a signaling protocol designed specifically for the Internet, RSVP 84 Version 1 (RSVPv1)[1][2][3] distinguishes itself by a number of 85 fundamental ways, particularly, soft state management, two-pass 86 signaling message exchanges, receiver-based resource reservation and 87 separation of QoS signaling from routing (in the sense that RSVP 88 messages follow normal IP routing). However, RSVP end-to-end 89 signaled QoS for the Internet has not become a reality. One reason 90 for this is regarded the complexity brought by multicast [8]. In 91 fact, vast majority of applications do not use multicast in reality. 92 Some multicast protocols (e.g., PIM-SM [4]) even consider multicast 93 as a function built on top of unicast routing rather than as an 94 integral part of it. We notice that multicast is not listed as a 95 (mandatory) requirement in the NSIS requirements draft [7]. 97 This draft analyses ingredients of RSVP Version 1 which are needed to 98 support multicast. Compared with standard RSVP, the following 99 features could be simplified or would even not be needed if multicast 100 is removed from RSVP: 102 o Unnecessary reservation styles and scope object in the signaling 103 protocol; 105 o Limitation on receiver-initiation; 107 o Coupled QoS specification and signaling support; 109 o Complex state structure and merging operation in the routers for 110 the signaling; 112 o Killer problems and error/failure handling. 114 This list might not be comprehensive, but we believe it covers main 115 features. We find that removing multicast capability from RSVP 116 generic signaling (and adpting related functionalities accordingly) 117 will make it considerably more light-weight. 119 2. Multicast-Influenced Ingredients in RSVP 121 This section analysis the ingredients in RSVPv1 influenced by 122 multicast. 124 2.1 Reservation Styles and Scope Object 126 To accommodate the multipoint-to-multipoint multicast applications, 127 RSVP was designed to support a vector of reservation attributes 128 called the "style". There are two attributes in RSVPv1: 130 Sharing attribute, with value "Shared" (all senders share a single 131 reservation) or "Distinct" (every sender has a seperate 132 reservation); 134 Sender Selection attribute, with value "Explicit" (select 135 explicitly a specific sender), "Wildcard" (applies to all 136 senders). 138 2.2 Limitation on Receiver-Initiated Reservation 140 Receiver-initiated is critical for RSVP to setup multicast sessions 141 with a large number of receivers. RSVP is optimized for a large 142 number of receivers with heterogeneous request, and therefore deploys 143 the receiver-initiated approach: a receiver initiates a reservation 144 request at a leaf of the multicast distribution tree, travelling 145 towards the sender. Whenever a reservation is found to already exist 146 in a node in the distribution tree, the new request will be merged 147 with the existing reservation. This could result in fewer signalling 148 operations for the RSVP nodes close to the sender, and new receivers 149 are handled completely by the receivers and the network without 150 bothering the sender. In comparison, for sender-initiated 151 reservation, when the reservation request travels up the multicast 152 tree towards the intended heterogeneous receivers, it is necessary to 153 distribute its reservation request information to all hops on the 154 multicast tree between source and receivers. This implies gathering 155 receivers' QoS information from receivers beforehand and results in 156 more signaling overhead. 158 2.3 Coupled QoS Specification with the Generic Signaling Protocol 160 To effectively signal QoS to the network, Path messages carry traffic 161 characteristic information (Sender_TSpec) as well as network 162 capability information gathered (ADSpec), while a Resv message 163 carries QoS information (FlowSpec, which includes TSpec and RSpec) 164 requested by the receiver. These specs are particularly designed for 165 multicast QoS resource reservation in the Integrated Service model, 166 where FlowSpecs should be merged when a Resv message is received by 167 an RSVP router where multicast delivery replicates data packets. 169 2.4 Complex State Merging Operation in the Routers for Signaling 171 Each RSVP router uses a Path state to maintain a table of TSpec 172 information for each multicast session, in addition to outgoing 173 interfaces of the previous RSVP hop and previous RSVP hop addresses. 174 An RSVP router also uses a Resv state to maintain next RSVP hop 175 address (used to distinguish its route from other multicast session) 176 and FlowSpec. When a router finds multicast delivery replicates data 177 packets, those specs related to the downstream reservations should be 178 merged, and appropriate reservation parameters should be passed 179 upstream. 181 2.5 Killer Problems and Error/Failure Handling 183 For reservation errors (e.g., admission control fails), a ResvErr 184 message should be reported to all of the responsible receivers. 185 Furthermore, it may result in "killer problems", i.e., if the path 186 towards the source has sufficient resources for the smaller of the 187 reservations but not for the merged request for the multicast, then 188 the effect of merging can be to deny reservations to both. 189 Therefore, the error processing of in RSVPv1 is rather complex. 190 Furthermore, a blockade state is introduced to solve the one of the 191 killer problems (KR-II), which is denial of (reservation) service by 192 a large and failing reservation. After a reservation's failure is 193 recorded in the blockade state created by ResvError messages, merging 194 will take this into account. 196 3. Towards a Light-weight RSVP: RSVP Lite 198 Based on the analysis above, this section describes how RSVP would 199 look like if removing its multicast capabilities and adapting other 200 related functionalizties of RSVP. For the convenience of the 201 following discussion, the abbreviation "RSVP Lite" is used to stand 202 for the possible feature set that follows. 204 Like in RSVPv1, soft-state and security mechanisms would still be 205 interesting to be used in RSVP Lite; signaling in the RSVP Lite is 206 also separated from routing in routers; the data flow definition 207 follows the same (i.e., consists of a session = and a filter spec = ). 210 However, RSVP Lite will bring a number of simplifications to RSVPv1. 211 In the following paragraphs, these features are briefly described. 213 3.1 No Reservation Styles and Scope Object 215 Styles in RSVPv1 are used for specifying the sender set for a 216 reservation request and whether these senders share a single 217 reservation. Beside, a scope object is used in Resv messages to 218 carry an explicit list of sender hosts towards which the information 219 in the message is to be forwarded. In RSVP Lite a receiver has only 220 one sender, therefore styles are not needed any more. Then all 221 related burden like merging are released from RSVP Lite. 223 3.2 Decoupling Signaled Data from Signaling 225 Path/Resv messages will not be responsible for creation and merging 226 of multicast reservation sink trees, they are only responsible for 227 creation and maintaining the appropriate states. The signaled data 228 are handled by upper level protocol(s) being carried by RSVP Lite 229 (e.g., ALSP described in [10]). Typically, one-way service signaling 230 (Path message) would suffice for setting-up the states from any node 231 towards another node in the Internet. However, to give the signaling 232 source a chance to see whether and how its service signaling (Path) 233 has been succeed, a confirm message (Resv) still is necessary for 234 RSVP Lite, with an optional object to record the last failed node 235 (when failed). 237 3.3 No Restriction on Sender- or Receiver-Initiation 239 Unlike in RSVPv1, it is not necessary for RSVP Lite to be always 240 receiver-initiated, because there is only one receiver, and no 241 merging is necessary from the receiver to the sender. It is up to 242 the upper level of signaling protocols to decide which way to 243 initiate. In addition, RSVP Lite does not rely on the multicast 244 membership, therefore can initiate and respond the signaling at any 245 node in the Internet, i.e., the placement of its signaling source and 246 destination is flexible. Thus it is able to support other signaling 247 models like host-to-network and edge-to-edge in a simple way in 248 addition to end-to-end signaling. 250 3.4 Simpler State Management in Routers 252 In RSVP Lite, there is no need to keep blockade states in routers, 253 only Path and Resv states would suffice. Hop-by-hop refreshes are 254 also simpler since Path/Resv refreshment messages neither need to be 255 distributed towards the multiple receivers/senders nor need to be 256 merged. 258 3.5 Simplified Error Handling 260 Although there still are a few possibilities of error sources in RSVP 261 Lite, most of the issues like killer problems become rather easier to 262 handle since: (1) there is no need to merge states for multicast 263 sessions in the RSVP routers, so the number of possible error source 264 decreases; (2) the error reports can be simply returned back to the 265 unicast sender. 267 3.6 Message Types 269 The possible types for messages involved in the signaling process of 270 RSVP Lite are listed as follows. 272 Path (or Request): for signaling request and state refreshment. 273 This message in fact takes only part of responsibilities of 274 Path messages in RSVP, and the real semantic of the signaled 275 data is defined by seperate protocols. We call these seperate 276 protocols ``client protocols'' and an example is the QoS client 277 protocol. These client protocol elements are encoded into the 278 Path (Request) messages - and Resv (Response) message when 279 necessary - which are simular to the concept of ALSP [10]. 281 PathErr: for reporting errors in processing Path messages. 283 PathTear: for tear down of Path state. PathTear message is sent 284 by the sender towards the receiver or the IP address where the 285 Path (Request) was rejected to explicitly delete or adapt 286 associated states; 288 Resv (or Response): indicating whether a signaling request is 289 accepted and whether to adpt in the reverse direction 290 (``Commit'') or rejected (``Reject''). The actual reverse 291 directional functionalities (mainly reserve for resources) of 292 Resv message in RSVP is no longer necessary. However, in RSVP 293 Lite, two-pass message exchange would be still necessary for 294 setting up proper states in the nodes along the data path from 295 the signaling requester to the signaling receiver. A Resv 296 (Response) message with ``reject'' flag set shares the same 297 type as the ``Commit'' one, but the IP address where the Path 298 reservation is rejected can be included. This provides the 299 signaling sender a flexibility in deciding whether to still use 300 the signaled segment for its session, or to clean up the 301 established states along the path. 303 For QoS signaling purposes, it is further possible to simplify and 304 optimize traffic description and QoS specification in the QoS client 305 protocol by introducing a ``QoS profile (with acceptable and desired 306 QoS level)'' into the QoS-client protocol for RSVP Lite. To support 307 different QoS provisioning techniques and optimize the signaling 308 procedure, the FlowSpec in Resv messages and the SenderTSpec/ADSpec 309 in Path messages of RSVP could be unified to a ``QoS profile'', e.g., 310 as defined in [14]. In the QoS profile of a Path (Request) message, 311 the sender can state its desired QoS and (minimally) acceptable QoS, 312 as well as its traffic characteristics (this allows the routers a 313 flexibility to dynamically adapt its reservation in dynamic 314 environments). A QoS profile with actually reserved QoS information 315 can be attached in the Resv (Response) message. 317 3.7 Mobility Consideration 319 TBD - Ideas of existing RSVP mobility schemes e.g., "Localized RSVP" 320 [12], "Mobile Extension for RSVP" [13] can be ported. It is also 321 possible for RSVP Lite to release the unused states and establish new 322 states without much pain following the ideas of mobility/route change 323 handling in CASP design [11]; special attention should be paid to 324 session identifiers. 326 3.8 Multicast Consideration 328 TBD - It would be useful for RSVPm/oMC to provide limited support for 329 some of multicast models. One possibility is to provide a special 330 interface to access the multicast routing tables. A limited support 331 for SSM multicast [9] is provided in CASP [11] and its idea may also 332 applies for RSVP Lite. 334 3.9 Potential Advantages of RSVP Lite 336 According to the discussion above, RSVP Lite potentially has a number 337 of advantages over RSVPv1: 339 Reduction in signaling set-up time. Because RSVP Lite can be 340 sender- and receiver-initiated without additional message 341 exchange, the signaling set-up time will be one-pass less than in 342 RSVPv1 in a sender-initiated signaling scenario. 344 Different modularity and more flexibility. RSVP Lite does not 345 intend to optimize for multicast, instead keeping the RSVP Lite 346 signaling integrants as minimal as possible, while freely putting 347 initiator and responder. Decoupling signaled data and signaling 348 message makes it more flexible and applicable to many other 349 signaling purposes besides QoS signaling. 351 Reduction in processing overhead due to (1) no need to carry 352 unncessary component and interpret signaled data in the basic 353 signaling protocol (RSVP Lite), (2) no need to merge for multicast 354 sessions and (3) simpler handling of errors and failures. 356 4. Security Considerations 358 By removing multicast support from RSVP, message processing is 359 simplified as explained throughout this document. However, there is 360 little room for optimization in security aspect. Integrity and 361 replay protection of RSVP signaling messages as offered by RFC2747 362 [5] is still required to provide security on a hop-by-hop basis. 363 Additionally, the integrity handshake mechanism used for recovering 364 from host or router crash to offer sequence number resynchronization 365 is required. In order to support policy based admission control and 366 authentication of the user via Kerberos, digital signature or plain- 367 text credentials the objects described in [6] have to be present. 368 Multicast processing of the policy locator inside the POLICY_DATA 369 object can be simplified in such a way that the policy locator is 370 copied from the received to the new message. The same procedure has 371 to be applied for the AUTH_DATA object which is also left unchanged 372 and forwarded (i.e. copied to the new RSVP message). 374 Section 7 of [5] states that in the multicast case all receivers must 375 share a single key with the Kerberos Authentication Server (i.e. a 376 single Kerberos principal is used). Removing multicast allows 377 avoiding the case where all receivers must share a single key. 379 Whether it is possible to simplify processing of POLICY_DATA objects 380 altogether needs further investigation. 382 5. Acknowledgement 384 Mehmet Ersue and Robert Hancock provided useful comments. 386 References 388 [1] Braden, R., Estrin, D., Berson, S., Herzog, S. and D. Zappala, 389 "The Design of the RSVP Protocol", ISI Final Technical Report , 390 Jul 1996. 392 [2] Zhang, L., Deering, S., Estrin, D. and D. Zappala, "RSVP: A New 393 Resource Reservation Protocol", IEEE Network, Volume 7, Pages 394 8-18, Sep 1993. 396 [3] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 397 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 398 Specification", RFC 2205, Sep 1997. 400 [4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 401 Handley, M. and V. Jacobson, "Protocol Independent Multicast- 402 Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, Jun 403 1998. 405 [5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic 406 Authentication", RFC 2747, Jan 2000. 408 [6] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 409 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 410 3182, Oct 2001. 412 [7] Brunner, M., "Requirements for Signaling Protocols", draft- 413 ietf-nsis-req-04 (work in progress), Aug 2002. 415 [8] Freytsis, I. and et al, "Next Steps in Signaling: Framework", 416 draft-ietf-nsis-fw-00 (work in progress), Oct 2002. 418 [9] Bhattacharyya, S. and et al, "An Overview of Source-Specific 419 Multicast(SSM) Deployment", draft-ietf-ssm-overview-03 (work in 420 progress), Mar 2002. 422 [10] Braden, B. and B. Lindell, "A Two-Level Architecture for 423 Internet Signaling", draft-braden-2level-signal-arch-00 (work 424 in progress), Nov 2001. 426 [11] Schulzrinne, H. and et al, "CASP - Cross-application Signaling 427 Protocol", draft-schulzrinne-nsis-casp-00 (work in progress), 428 Sep 2002. 430 [12] Manner, J. and et al, "Localized RSVP", draft-manner-lrsvp-00 431 (work in progress), May 2002. 433 [13] Shen, C. and et al, "Mobility Extensions to RSVP in an RSVP- 434 Mobile IPv6 Framework", draft-shen-nsis-rsvp-mobileipv6-00 435 (work in progress), Jul 2002. 437 [14] Westphal, C. and et al, "Context Relocation of QoS Parameters 438 in IP Networks", draft-westphal-seamoby-qos-relocate-00 (work 439 in progress), Jul 2001. 441 Authors' Addresses 443 Xiaoming Fu 444 University of Goettingen 445 Telematics Group 446 Lotzestr. 16-18 447 Goettingen 37083 448 Germany 450 EMail: fu@cs.uni-goettingen.de 452 Cornelia Kappler 453 Siemens AG 454 Siemensdamm 62 455 Berlin 13623 456 Germany 458 EMail: Cornelia.Kappler@icn.siemens.de 460 Hannes Tschofenig 461 Siemens AG 462 Otto-Hahn-Ring 6 463 Munich 81739 464 Germany 466 EMail: Hannes.Tschofenig@mchp.siemens.de 468 Full Copyright Statement 470 Copyright (C) The Internet Society (2002). All Rights Reserved. 472 This document and translations of it may be copied and furnished to 473 others, and derivative works that comment on or otherwise explain it 474 or assist in its implementation may be prepared, copied, published 475 and distributed, in whole or in part, without restriction of any 476 kind, provided that the above copyright notice and this paragraph are 477 included on all such copies and derivative works. However, this 478 document itself may not be modified in any way, such as by removing 479 the copyright notice or references to the Internet Society or other 480 Internet organizations, except as needed for the purpose of 481 developing Internet standards in which case the procedures for 482 copyrights defined in the Internet Standards process must be 483 followed, or as required to translate it into languages other than 484 English. 486 The limited permissions granted above are perpetual and will not be 487 revoked by the Internet Society or its successors or assigns. 489 This document and the information contained herein is provided on an 490 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 491 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 492 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 493 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 494 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.