66 th IETF 회의참가보고서 2006 년 9 월 경북대학교통신프로토콜연구실 김동필 (dpkim@cs.knu.ac.kr) 김상태 (saintpaul1978@mail.knu.ac.kr) 하종식 (mugal1@dgssm.org) 윤성식 (tothepolaris@cs.knu.ac.kr) 주수경 (jusukyoung@hanmail.net) 요약 본보고서는경북대학교통신프로토콜연구실원들이 66차 IETF 회의참가후작성한보고서이다. 본보고서는 2006년 7월 9일부터 14일까지캐나다몬트리올에서개최된제66회 IETF 표준화회의의참가보고서이다. 여기서는 tsv, shim6, mipshop, rserpool, dccp Working Group에서다루고있는내용과이번회의에서발표된의제와차후진행사항등에대해기고한다. 1
목 차 1. 서론... 3 2. TSVWG... 3 2.1 WG 개요... 3 2.2 WG 표준문서... 4 2.3 66차 IETF 회의논의사항... 6 3. SHIM6...10 3.1 SUMMARY OF THE WG SHIM6...10 3.2 INTRODUCTION TO SHIM6 WG DOCUMENTS...12 3.3 DISCUSSION ABOUT SHIM6 AT THE MEETING...13 4. MIPSHOP...15 4.1 MIPSHOP WG 개요...15 4.2 WG 표준문서...16 4.3 WG INTERNET DRAFTS...21 4.4 IETF 66TH...24 4.5 결론...26 5. RSERPOOL...27 5.1 RELIABLE SERVER POOLING...27 5.2 WORKING GROUP 표준문서...28 5.3 회의논의사항...30 6. DCCP...32 6.1 서론...32 6.2 DCCP 개요...32 6.3 SESSION AGENDAS AND PRESENTATIONS...34 6.4 전망...35 7. 결론...35 2
1. 서론제66회 IETF (The Internet Engineering Task Force ) Meeting이 2006년 7월 9일부터 7월 14일까지캐나다의몬트리올에서개최되었다. IETF에서는차기인터넷표준기술규격을제정하기위해 8개주제의 130여개 Working Group에서각각회의가이루어진다. 인터넷구조의발전과인터넷의원활한실행을위한표준화와관련된네트워크설계자, 기술자, 제조업체그리고연구원들에게넓게개방된국제적인공동체라고볼수있다. 본문서에서는 tsv, shim6, mipshop, rserpool, dccp Working Group에서다루고있는내용과이번회의에서발표된의제와차후진행사항등에대해기고한다. 2. TSVWG 2.1 WG 개요 - Transport Area는기존의워킹그룹의범위에존재하지않거나, 새로운워킹그룹의 formation을정당화하지않는 transport topic을다루는 RFC의개발과 publication을위한제안을받아들인다. TSVWG은 IETF의그러한 work item을개발하기위한포럼으로서 serve한다. TSVWG 메일링 리스트는그것들이발생하는경우, 그러한 work item들에대한 open discussion forum입니다. The working group은논의를요구하는 active한제안이있을경우 meeting을가진다. The working group milestones은현재 work item들과그것에연관된 milestone을반영할필요로서업데이트된다. (A) Stream Control Transmission Protocol (SCTP) 의 Maintenance는 SCTP 스펙의버그수정과, 표준 track에따르는진행을포함하고있다. 이러한 work item은또한 SCTP에대한소수의 module extension을포함하고있다. 현재, 이것들은 socket API와 threat 분석문서와같은 SCTP-ADDIP, SCTP-AUTH and SCTP-PADDING을포함하고있다. 안정된스펙을유지하기위해서 TSVWG 내의 SCTP의추가적인연구는 Area Director approval을요구한다. (B) Resource Reservation Protocol (RSVP) 의 Maintenance는 RSVP스펙의버그수정과표준 track에따르는진행을포함하고있다. 이러한 work item은또한 RSVP에대한소수의 module extension 또는특정어플리케이션시나리오를 address하기위한자문문서를포함하고있다. 안정된스펙을유지하기위해서 TSVWG 내의 RSVP의추가적인연구는 Area Director approval을요구한다. (C) IP Differentiated Services (DiffServ) 메커니즘의 Maintenance는대개특정어플리케이션시나리오내에서 DiffServ의사용에관한자문문서를포함하고있습니다. DiffServ에관계된다른 work item들은 Area Director approval을요구한다. 3
(D) 선택된다른 work item들은보통역사적인이유때문에 TSVWG에존재한다. 이work item들은 TCP를위한 extended statistics MIB, 그리고 TCP와 IP를위한 the quick-start 메커니즘을포함한다. 본보고서에서는 SCTP 관련부분만다루도록한다. 2.2 WG 표준문서 2.2.1 완료된 RFC 1) Stream Control Transmission Protocol (SCTP) Checksum Change (RFC 3309) (34670 bytes) updates RFC 2960 - 기존의 Adler-32 checksum 방식이 error detection 에취약하여 32 bit CRC checksum 방식으로변경한다. 2) Transport Layer Security over Stream Control Transmission Protocol (RFC 3436) (16333 bytes) - RFC 2960 및 RFC 3309에정의된 SCTP 상에서, RFC 2246에정의된 Transport Layer Security (TLS) 프로토콜의사용법을기술한다. TLS의유저는, SCTP에의해서제공되는특징, 즉 line blocking의 head를회피하는 multiple stream의지원, network level fault tolerance를제공하는 multi-homing의지원을이용할수있다. 게다가 IP주소의동적인재구축을지원하는 SCTP의확장의논의도지원된다. 3) SCTP Partial Reliability Extension (RFC 3758) (50999 bytes) - SCTP endpoint가 peer에게 cumulative ack point를앞으로이동시키라는 signal을보내는것을가능하게하는 SCTP 확장에대해기술한다. SCTP association의양측이이확장을지원하는경우, 그것은 upper layer 프로토콜에부분적으로신뢰할수있는 data 전송서비스를제공하기위한 SCTP implementation에의해사용된다. 이문서는, INIT 및 INIT ACK, 새로운 FORWARD TSN chunk type을위한새로운파라미터로구성된프로토콜확장에대해기술하고, 이메카니즘에의해서 upper layer에제공할수있는, 부분적으로신뢰할수있는서비스의하나의예를제공한다. 4) Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (RFC 4460) (215405 bytes) - 6 개의상호운용적사건과 5년의구현, 테스팅, SCTP 이용을경험하는동안에발견된문제를편집한것이다. 4
2.2.2 진행중인 Internet Draft 1) Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration (draft-ietftsvwg-addip-sctp-15.txt) - SCTP 의시나리오확장을위해, 존재하는 association 의 IP 주소정보의형태변경, 멀리떨어져있는 primary path 의설정, association 설정동안 adaptation layer 정보의교환등이추가된다. 이러한확장으로인해, 물리적인인터페이스카드를추가 / 삭제할수있는계산적인또는네트워킹플랫폼에대해기존의 association 의인터페이스를늘리는우아한메소드를제공할수있다. IPv6 에대해서는기존의 association 의 renumbering 을가능하게한다. 또한, peer 가 primary 목적지주소를설정하는것을요구하는메소드를제공하는데, 하나의주소가삭제되는경우나엔드포인트가패킷을받도록준비된주소에대한정보가미리정의되어있는경우유용하다. 마지막으로이러한특징은엔드포인트가 association 설정중에정보교환을허락함으로써수정하지않고 SCTP 의유용성을확장하는데사용될수도있다. 2) Sockets API Extensions for Stream Control Transmission Protocol (SCTP) (draft-ietf-tsvwgsctpsocket-13.txt) - SCTP 의 mapping 을기술한다. 소켓 API 는많은 OS 에적합한인터넷프로토콜의표준 mapping 을제공한다. SCTP 는 TCP 의많은특성을제공할뿐만아니라 SCTP 는, TCP 의특성의대부분을제공할뿐만아니라 UDP 에가까운 semantic 을섞은새로운프로토콜이다. 이문서는 SCTP 를이용하기위해기존소켓 API 를사상하는방법을정의한다. 3) Authenticated Chunks for Stream Control Transmission Protocol (SCTP) (draft-ietf-tsvwgsctp-auth-03.txt) - SCTP 의새로운 chunk type, 몇몇의파라미터와프로시저를기술한다. 새로운 chunk type 은 sender 와 receiver 사이에공유되는 key 를사용함으로써 SCTP chunk 를인증하기위해사용됩니다. 새로운파라미터는공유되는 key 를확립하기위해서사용된다. 4) Stream Control Transmission Protocol (draft-ietf-tsvwg-2960bis-02.txt) - SCTP 는 IP 네트워크에서 PSTN signaling 메시지를전송하기위해디자인되었으나, 폭넓은 application 에서사용할수있습니다. SCTP 는 IP 같은비연결성 packet 네트워크의위에서운용되는신뢰성있는전송프로토콜이다. SCTP 는중복되지않는전송, MTU 크기에알맞은 data fragmentation, multiple stream 내에서순차적메시지전송, 여러 user message 를하나의 SCTP 패킷으로 bundling, multi-homing 을지원함으로써네트워크레벨에서의결함을포용등의서비스를제공한다. 5
5) Padding Chunk and Parameter for SCTP (draft-ietf-tsvwg-sctp-padding-00.txt) - padding chunk 와 padding parameter 를정의하고, reciver 측에서요구되는프로시저들을기술합니다. PAD chunk 는 path MTU 발견을위해사용된다. 2.3 66차 IETF 회의논의사항 2.3.1 가. 회의 Agenda TSVWG Agenda for IETF 65 (Montreal) Monday July 10th, 2006 0900-1130 1) Chair's 9:00-9:15 Agenda Bashing (15 min) NOTE WELL Document Status and Accomplishments New Charter New Milestones 2) Kwok - Aggregation of Diffserv Service Classes 9:15-9:25 draft-ietf-tsvwg-diffserv-class-aggr-00 (10 min) 3) Randy and Michael - 2960bis and SCTP Padding Chunks 9:25-9:40 draft-ietf-tsvwg-2960bis-02 (15 min) draft-ietf-tsvwg-sctp-padding-00 4) Marushin - SCTP ASCONF Chunk Transmission Ext. 9:40-9:45 draft-marushin-sctp-asconfext-01 (5 min) 5) Randy and Michael - SCTP Threats and Socket 9:45-9:55 draft-ietf-tsvwg-sctpthreat-00 (10 min) 6) Francois - RSVP Extensions for Emergency Services 9:55-10:05 draft-lefaucheur-emergency-rsvp-02 (10 min) 7) Bob - Policing and Accountability for Causing Congestion on Borders draft-briscoe-tsvwg-re-ecn-tcp-02 10:05-10:25 draft-briscoe-tsvwg-re-ecn-border-cheat-01 (20 min) draft-briscoe-tsvwg-re-ecn-apps-00 6
8) Bob and Phil - Controlled Load 10:25-10:45 draft-briscoe-tsvwg-cl-phb-02 (20 min) draft-briscoe-tsvwg-cl-architecture-03 9) Francois - RSVP Ext for Admission Control over DS using PCN 10:45-10:55 draft-lefauchuer-rsvp-ecn-01 (10 min) 10) Georgios - Resource Unavailability PDB 10:55-11:05 draft-karagiannis-ru-pdb-02 (10 min) 2.3.2 논의된내용정리 1) Randy and Michael - 2960bis 가 ) 변경사항 - 빠졌던 Adler-32가 CRC32c로변경 - 빠졌던 article 또는 2~3개의 type과문법교정 - 나타나지않았던섹션이다시나타나게함 - Refernece가 RFC1750에서 4086으로업데이트 - 명료성을위해공백추가 - CRC32c의코드가 appendix 뒤에추가나 ) 향후진행방향 - 최후점검및 WG으로부터의 comment가필요 - RFC 2960, 3309, 4460에서빠트린것 - XML로의 conversion이발생시킨문제점 2) Randy and Michael - SCTP Padding Chunks 가 ) 변경사항 - 지난회의에서논의된 motivation이추가되지않음 - PMTU discovery를위한요구나 ) 향후진행방향 - TWGLC는 WG가한가할때진행 3) Marushin - SCTP ASCONF Chunk Transmission Ext 가 ) 논의사항 - ASCONF transmission의한계 - 미해결된 ASCONF chunk가있을때새로운 ASCONF chunk를보내는것은금지 7
- IPv4와 IPv6를지원하는노드 A와 IPv4만지원하는노드 B가있을때, 노드 A가 IPv4 주소를잃어버리면다른 IPv4 주소를얻어야하지만, A는 IPv6 주소만가지고있으므로 ASCONF를전송할수없다. 한번이런일이일어나면따라오는 ASCONF 또한 block된다. - 노드는하나의 interface와하나의 IP주소만을가지고, interface가다운되면노드는새로운주소를얻어야하지만, ASCONF-ACK가 return되지않아서주소는연결불가능이된다. 다른주소를얻어도 ASCONF는전송할수없다. - Cumulative ASCONF chunk - ASCONF를 bundling 할때, 모든미해결 ASCONF는순서대로 bundle되어야함 - ASCONF_ACK는 bundled ASCONF의 source 주소로 return되어야함 - Receiver는 ASCONF_ACK를모든 ASCONF에대하여보내주어야함 - ASCONF_ACK 또한 bundle되어야함 8
1,2 3,4,5 A ASCONF 1,2 ACK 1,2 B Cache 1,2 Retransmition ASCONF 3,4,5 Cache 3,4,5 ACK 3,4,5 ASCONF 1,2,3,4,5 Ignored 4) Randy and Michael - SCTP Socket 가 ) 변경사항 - Spelling 문제수정 - 새로확장된 sndrcvinfo 추가 - next_flags, next_stream, next_associd, next_length, next_ppid 추가 - 4개의새로운소켓옵션 - next_xx 필드가유효하는지를나타내는 flag - SCTP_GET_PEER_ADDR_INFO은주소와함께사용되고 assoc-id가사용되지않을때 assoc-id가 return되는상태에추가된설명을가짐. 나 ) 향후진행방향 - 문서는 AUTH, ADDIP, 2960bis WGLC를기다린후, 얼마후에배포될예정 - 이문서는 BIS, ADD-IP, AUTH 만을 cover함 - socket API 확장을요하는 SCTP의추후확장은변경사항을기술한문서의한섹션에서다뤄져야함. - 아직보안섹션에일부 delivery API의적합한구현을위한작은비트를추가할필요가있음 4) Randy and Michael - SCTP threats 가 ) 변경사항 - WG 문서로만들어졌으며, 문서는거의변경된것이없음 - 2960 과 ADD-IP의알려진모든 threats를다룸 - 대응책이 2960Bis와 ADDIP에 AUTH와함께포함 - 한공격이아직대비되지못함 : 큰 INIT-ACK에비해작은 INIT로행해져야함 - padding draft가프로시저를가지지않은메커니즘을가짐 9
나 ) 향후진행방향 - 문서는완성되었으며, 이문서는 RFC4460과진행중인 BIS 작업처럼 SCTP에서의변경에배경을제공 - WGLC는 WG가한가할때진행 3. shim6 3.1 Summary of the WG shim6 멀티호밍 (Multihoming) 이란어떤사이트 (site) 1 나단말이하나이상의 ISP(Internet Service Provider) 로부터두개이상의연결성을확보하는것을의미한다. 멀티호밍은그것이적용되는네트워크계층에따라통신사업자수준의멀티호밍, 사이트수준의멀티호밍, 단말수준의멀티호밍으로나누어볼수있다. 멀티호밍은그적용분야에따라목적이조금씩다르겠지만대체로다음과같은장점을제공한다 : 물리적인링크의중복성 (redundancy) 을통한오류복구 (fault tolerance) 네트워크부하의공유및분산 (load sharing and balancing) 다중인터페이스사용을통한네트워크접속투명성제공대역폭증가이동성지원 이러한장점들로인해멀티호밍기법은이미대부분의사이트에서이루어지고있다. 특히 WLAN, CDMA, WiBro 등다양한액세스기술이융합된 NGN 환경으로다가갈수록멀티호밍의요구사항은더욱증가될것이며, 이종망간의이동성까지고려할때멀티호밍에관한요구사항은지금과같이사이트수준뿐만아니라단말수준에이를것으로예상된다. 현재의 IPv4 네트워크에서의사이트멀티호밍은 BGP(Border Gateway Protocol) 에의해자연스럽게제공되고있다. BGP는 AS(Autonomous System) Number가다른자치네트워크간에서로라우팅정보를주고받아도메인간라우팅을가능하게하는프로토콜이다. BGP 프로토콜을사용하면, 멀티호밍을구성한사이트와연결된 ISP는자신이서비스하는것보다더긴 IP 주소블록과자신이서비스하지않는 IP 주소블록을상위로전달하는것만으로, 특별히다른메커니즘이필요없이간단히멀티호밍을지원할수있게된다. 반면, BGP를사용한멀티호밍방법은 DFZ(Default-free zone)2에서의라우팅테이블의급증을초래하는심 1 (site) IP (addressing) (routing) Entity RFC 3852 IPv6 Site-Multihoming Goals[3]. 2 DFZ (Default-free zone) full BGP table full BGP table. 10
각한단점을가지고있다. IETF에서는이문제를해결하기위하여 RFC 2260 Scalable Support for Multi-homed Multi-provider Connectivity) 표준의제정으로다중연결된 ISP 중하나에문제가발생한경우에만라우팅정보를상위로전달하는 (Auto-route injection) 방법을제시하였다. IPv6는프로토콜의특성상한호스트가여러주소를가질수있으며, IPv4의 CIDR 3 과같이 ISP를중심으로계층적으로구성이되어있다. 그러나 IPv6의주소는 128bit로 IPv4보다 4기존의것보다훨씬더많은 Network Prefix 들로인해기존의방법대로멀티호밍을구성하는것은확장성면에서문제가있음을쉽게알수있다. IETF에서도 RFC 2772, 6Bone Backbone Routing Guidelines 을표준으로제정하여 6Bone(IPv6 Backbone Network) 에서다음과같은기존 IPv4 방식의멀티호밍을금지하고있다 : ISP는다른 ISP의 IP 주소블록을상위로절대전달하지않는다. 사이트는그들이할당받은 IP 주소블록보다긴주소블록을상위 ISP에게절대전달하지않는다. 이두가지제한으로인해 IPv6 멀티호밍을위해서는다른해법이필요한상황이고, IETF에서는우선 IPv4 멀티호밍표준인 RFC 2260을 IPv6에맞게수정한 RFC 3178 IPv6 Multihoming Support at Site Exit Routers 을제정하였다. 이것은멀티호밍을구성한사이트의출구라우터 (Exit Router) 와해당사이트에연결된 ISP간의터널링인터페이스를사용하여 ISP의문제발생시연결성을보장하는방법이다. 이방법은멀티호밍자체는해결할수있지만터널링에따른성능저하나 ISP 자체의문제에는대처하지못하며, 특히멀티호밍의다른장점인부하분산및공유, 이동성지원등많은부분에서다른해결책이요구되고있다. 이와관련하여 IETF Multi6(Site Multihoming in IPv6) WG에서는여러가지해결책에관한기고서를제안받았다. 대표적으로 MIP(Mobile IP) 의 binding을이용한방법, IPv6의 Router Renumbering에의한방법, 멀티호밍을지원하는 L4계층의프로토콜인 SCTP(Stream Control Transmission Protocol) 을이용하는방법등이있으나 Multi6에서는 HIP(Host Identity Protocol) 의 ID/Locator의분리개념을도입하고, 하나의 ID와여러 Locator간의매핑 (mapping) 정보를 L3와 L4계층사이에추가하는 Layer 3 Shim (L3Shim) 해법을제안하였다. Shim6(Site Multihoming by IPv6 Intermediation) WG는이러한 L3Shim 해법에관한표준화를진행하기위하여 Multi6 WG 후속으로시작이되었다. Shim6 WG에서는 L3Shim을사용한멀티호밍의요구사항으로크게다음과같은것들을언급하고있다. IPv6 만을고려하며 IPv6 NAT 장치는없다고가정 3 IP Class, Class C (24bit network prefix) IP CIDR(Classless Inter-Domain Routing). 11
기존에존재하는세션과새로설정하는세션의 Re-homing의처리상위계층에서는고정된 ULID(Upper Layer Identifier) 만볼수있으며 Shimm 계층아래의주소변경은볼수없다. 수많은멀티호밍지원사이트들이존재하는경우에도전체라우팅시스템이지원할수있게확장성을고려한다. Shim6를지원하는노드가이동성지원을위해 MIPv6를사용할수있지만이동성에관련된부분은직접적으로다루지않는다. 정적또는동적인주소를다루는최적화된방법을제안한다. 이외에도언급되고있는요구사항들은 Shim6 WG Charter 를참조한다. 3.2 Introduction to shim6 WG Documents 초기에채택되었던드래프트문서들 (Architecture, Functionality 등 ) 은현재유효기한이만기가되어서현재유효한 Shim6 WG의 WG 문서들은다음과같다. Level 3 multihoming shim protocol - Shim6의기본프로토콜규격문서로, 전체적인설계의목적과프로토콜에관한개요, 세세한메시지형식등을다룬다. Hash Based Address (HBA) - 멀티호밍을지원하는사이트가 Prefix가서로다른여러개의주소를안전하게바인딩 (binding) 하기위한방법을다룬다. 기본적인아이디어는주소자체에여러 Prefix정보를포함하는것이며, 이를위해사용가능한 Prefix들과난수 (random number) 를사용하여생성한 Hash Digest를 Interface ID라정의하고이 Interface ID 앞부분에각각의 Prefix를추가하여생성한여러개의주소를 HBA(Hash Based Address) 라고부른다. Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming - Shim6를사용하여통신중인두호스트간의실패탐지 (Failure Detection) 와새로운주소쌍으로의전환을위한조사 (Exploration) 규약을정의한다. Default Locator-pair selection algorithm for the SHIM6 protocol - Shim6를지원하는두 Endpoint간에기본적인통신을위한 Locator 쌍의결정에관한문서로, 기본적인고려사항과실제 Locator쌍을결정하는알고리즘들다룬다. Applicability Statement for the Level 3 Multihoming Shim Protocol - IPv6 네트워크에서멀티호밍의지원을위한 Shim6 프로토콜의적용가능성을논의하는문서로서, 응용시나리오및 Shim6의 Capability, 멀티호밍지원은위한다른프로토콜과의연동문제등을다룬다. 현재까지 RFC 로승인된것은없고 HBA 문서만이 AD(Area Director) Evaluation 과정에있다. 12
3.3 Discussion about shim6 at the meeting 3.3.1 Agenda 1) Administriva (5 minutes) - Mailing list: http://ops.ietf.org/lists/shim6/ - Scribe? - Blue Sheets - Agenda Bashing 2) Status of "base specification" document set (15 minutes) A. Level 3 multihoming shim protocol http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt B. Hash Based Addresses (HBA) http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt C. Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-05 3) SHIM6 Applicability A. Applicability (Marcelo Bagnulo, Joe Abley) (15 minutes) Applicability Statement for the Level 3 Multihoming Shim Protocol http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt 4) SHIM6 Implementation Report (10 minutes) A. Progress report on SHIM6 Implementation, Taewan You (ETRI) 5) SHIM6 Extension Drafts A. Locator Pair Selection (Marcelo Bagnulo) (15 minutes) Default Locator-pair selection algorithm for the SHIM6 protocol http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-00.txt B. ESD (Erik Nordmark) (15 minutes) Extended Shim6 Design for ID/loc split and Traffic Engineering http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt ** Eric wont be able to make it this time around - so the chairs will request WG comments on the draft C. Ingress Filtering (Marcelo Bagnulo) (10 minutes) Ingress filtering compatibility for IPv6 multihomed sites http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-ingress-filtering-00.txt D. Privacy Analysis (Marcelo Bagnulo) (10 minutes) Privacy Analysis for the SHIM6 protocol 13
http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt E. Socket API (Shinta Sugimoto) (15 minutes) Socket Application Program Interface (API) for Multihoming Shim http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt 6) WG Direction 3.3.2 Results 1) Status of "base specification" document set Hash Based Address draft 문서는지난 2005년 10월에 WG Last Call을거쳐현재 AD(Area Director) Evaluation 중이고, Protocol Specification 문서는 2006년초에 WG Last Call을통과했고 Failure Detection과 Locator Pair Exploration은아직 Last Call를통과하지못했다. 그러나 AD에의해 Protocol Specification 문서는 Last Call을통과하지못한나머지두문서와함께검토되어야한다고요청되어서이번회의에서는나머지 3개의 Shim6 기본규격문서들 (Protocol Specification, Failure Detection and Locator Pair Exploration) 에대한 WGLC(Working Group Last Call) 을위한요청을했지만 CGA와 HBA간의 IPR 문제, IPsec과 ULID, HBA의보안성검토등의이유로합의를이루지못했다. 2) Ingress Filtering and Exit Path Selection (Marcelo Bagnulo) 이문서는네트워크에서의 Ingress Filtering과이미멀티호밍을구성한레거시사이트들과의연동에서발생하는문제를다루는방법들을논의한것으로, 이번회의를통해 WG Document로요청이되었다. 3) Socket API for multi-homing Shim (Shinta Sugimoto) 이문서는 Shim6를사용한멀티호밍의지원을위한 Socket API의규격이며, 이번회의를통해 WG Document로요청이되었다. 3.3.3 Future Work 회의의마지막부분에서 Shim6 WG의방향에관한논의가약간있었는데그것은이미기본규격이상당한분량으로작성되었으므로정말로필요한경우외에는추가하지않도록한다는것이다. 또한조금더표준화진행에속도를내어기본규격에만머무르지말고구현사례와정용성에관한 Feedback을좀더받자는논의가오고갔다. 또한기본규격들이 WGLC를거칠수있도록앞서나왔던문제점들에대한해결책을강구해야할것이다. 14
4. mipshop 4.1 MIPSHOP WG 개요 Mobile IPv6 는 IPv6를지원하는이동단말이새로운 IP 영역으로이동하더라도기존의 IP 영역에서부여받은 IPv6 주소를지속적으로사용할수있도록하는 IP 이동성지원프로토콜이다. 일반적으로, 이동단말이이종망네트워크환경에서기존영역에서다른 IP 영역으로이동할때, Mobile IPv6 기법에의해 IP 이동성이지원되더라도핸드오버수행기간동안 Signaling 오버헤드나데이터손실및네트워크지연등이빈번히발생하게된다. IETF MIPSHOP WG에서는 Mobile IPv6 동작중에발생하는 Signaling 오버헤드나상대적으로많은양의데이터손실등을보완하기위해 Mobile IPv6의확장된버전의 IPv6 기반핸드오버지원프로토콜개발에주력하였다. 이러한노력으로 Hierarchical Mobile IPv6 (HMIPv6, RFC 4140) 와 Fast Hierarchical Mobile IPv6 (FMIPv6, RFC 4068) 프로토콜들을설계하고 Experimental RFC로써표준화하였다. HMIPv6는 Mobile Node (MN) 과 Home Agent (HA), 그리고하나이상의 Correspondent Node (CN) 간에발생되는핸드오버 Signaling의양과핸드오버수행시간을줄일수있도록설계되었으며, FMIPv6는 MN이새로운링크에대한연결설정을완료한후, 곧바로기존링크에서새로운링크로 IP 연결성을보장해줌으로써핸드오버수행중데이터손실을줄일수있도록설계되었다. 더욱이, 현재 MIPSHOP charter에서는앞서표준화한 FMIPv6와 HMIPv6가 IEEE 802.11 네트워크에서어떻게동작하는지에대한구체적인시나리오에대한문서를 Informational RFC로표준화하였다. 현재까지, 본 WG에서는 FMIPv6와 HMIPv6에대한더많은구현결과를가지고많은성능분석을수행하고있으며, IEEE 802.11네트워크뿐만아니라, 향후차세대무선접속기술로써기대되고있는 IEEE 802.16(e) 및다른무선접속기술과의연동시나리오에대해표준화를진행시킬것을향후 MIPSHOP의 charter에포함하고있다. 뿐만아니라, 현재 IEEE 802.21 Media Independent Handoff (MIH) 서는이기종의무선접속기술들을지원하는이동단말환경에서핸드오버를지원하기위해 L1 과 L2 계층및상위계층에서요구되는핸드오버지원요구사항들을분석하고, 이들을 MI (Media Independent) Event Service (MIES), MI Command Service (MICS), and MI Information Service(MIIS) 등으로정의하고분류하였다. MIES는하부계층에서발생되는상태변화에대한정보를이벤트형식으로구성하여적절한핸드오버나무선통신을제공하도록하고있으며, MICS는이동단말이하부계층의상태변경을요구할때 Commend 형식으로구성하여제공하는정보교환으로써, 하부계층에더많은 MIES 정보를요구할때사용될수있다. 마지막으로, MIIS는현재속해있는서비스네트워크의위치정보나 topological 정보를제공하는 MIH의서비스중하나이다. 향후, MIPSHOP에서는 IEEE 802.21 MIH WG과연계하여 MIH에서진행중인핸드오버지원에대한서비스요구사항들을분석하고, MIH 서비스기반의 FMIPv6 및 HMIPv6 기반 IP 핸드오버지원시스템에대한추가적인표준화작업을진행할예정이다. 이를위해, 15
MIH서비스에대한정보를전달하기위해추가적인프로토콜을설계할예정이며, CN이 MIH 서비스를지원하지않더라도 L3 레벨에서 FMIPv6 와 HMIPv6에의해 MIH 기반 IP 핸드오버를지원할수있도록하는표준을제정할예정이다. MIPSHOP WG의표준화진행을위한 Working Items들은다음과같다. 1. HMIPv6의추가적인보완작업및이를새로운표준에반영 A. MN-MAP 보안고려사항에추가작업 B. 기존의 HMIPv6에대한보완 2. FMIPv6의추가적인보완작업및이를새로운표준에반영 A. AAA 프로토콜과 SeND의보안 Key를이용한 MN-AR (Access Router) 보안문제에 B. 기존의 FMIPv6 표준의보완 3. Informational RFC 반영을위한서로다른링크계층상에서 FMIPv6 응용프로그램개발 A. IEEE 802.16e 와 3G CDMA 2K 네트워크연동시나리오 3. 보안이강화된 MIPv6 Return Routability 메커니즘을개선하기위한표준문서작성 4. IEEE 802.21과 MIPSHOP간의상호연계를통한강화된 MIPv6 기반 IP 핸드오버표준화작업추진 4.2 WG 표준문서본절에서는현재까지 MIPSHOP WG에서표준화된문서에대해간략히서술한다. 4.2.1 Fast Handover for Mobile Ipv6 (RFC 4068) FMIPv6는기존의 Mobile IPv6의구현문제에서지적되고있는긴핸드오버지연시간을최소화시키기위해 L3 핸드오버가시작되기전, 미리핸드오버수행절차를진행하도록디자인된 Mobile IPv6의확장프로토콜이다. 일반적으로 IP 이동성에서핸드오버지연은크게 MD (Movement Detection) 과정과 CoA (Care of Address) 설정과정에서발생하는 IP 연결성지연부분과서비스노드로부터이동노드로직접데이터를받기위한 RR (Return Routability) 과정을포함하는 Binding Update 지연부분으로크게나눌수있따. FMIPv6에서는위의지연을줄이기위해링크계층의정보를이용한 L2 트리거와 L2 핸드오버이전에 L3 핸드오버를수행하게된다. 여기서 L2 핸드오버는 L2에서수행되는하부계층의핸드오버로써하드 (Hard) 핸드오버로써, IEEE 802.11 네트워크에서 AP (Access Point) 가 16
변경되는과정을말하며, L3 핸드오버는 Mobile IPv6 에서 CoA 주소가생성된절차를말한다. HA Packet IPv 6 in IPv6 Packet CN 4. HI PCoA NCoA PAR 5. H A ck NAR 1. RtS olpr 2. PrRtAdv 6. FBAck 8. FN A 3. FBU AP AP 0. M ov ement 7. Movement MN MN MN 그림 1 FMIPv6의동작과정 FMIPv6에는이동노드가 L2 핸드오버이전에 L3 핸드오버를수행하기위한 Predictive Mode 와 L2 핸드오버수행후 L3 핸드오버가수행되는 Reactive Mode 시나리오로구성된다. 그림 1에서와같이, Predictive Mode 의 Fast 핸드오버동작은최초 AP 스캐닝 에의해단말이이동해야할시점을 triggering 하면서시작된다. 이동노드는자신이이동가능한 AP를관장하는 NAR에관한정보를얻기위하여 PAR (Previous Access Router) 에 RTSolPr (Router Solicitation for Proxy Advertisement) 메시지를보내고, 그응답으로 NAR로부터 PrRtAdv (Proxy Router Advertisement) 메시지를받는다. 그리고이메시지에포함된 Prefix 정보로부터자신이사용할 NcoA (New Care of Address) 을생성하고그유효성을검증하기위해 FBU 메시지에 NCoA를담아서 PAR로보낸다. PAR은이동노드를대신하여 NCoA의유효성확인검사를위해서 NAR(New Access Router) 로 HI (Handover Initiate) 메시지를보내고, 그것에대한응답메시지인 Hack (Handover Acknowledge) 을수신한다. 그리고이유효성여부를이동노드에게통지하기위해서 Fback (Fast Binding Acknowledgement) 메지를보낸다. 이동노드가계속움직여 PAR 링크를벗어나면, PAR은이동노드에게전달할데이터를터널링 (tunelling) 을통해서 NAR로전달시킨다. 이동노드가 Fback를수신하고 NAR 링크에들어가게되면, FNA (Fast Neighbor Advertisement) 을 NAR에전송하여자신이접속을알리고이동노드에게배달된패킷을신속히수신한다. 17
반면, Reactive Mode 는 Predictive Mode 와마찬가지로이동노드는자신이이동가능한 AP를관장하는 NAR에관한정보를얻기위하여 PAR에 RtSolPr 메시지를보내고 NAR로부터그응답인 PrRtAdv 메시지를받는다. 그러나이동노드는이미 PAR영역을벗어나 NAR 영역으로들어가고있는상태이기때문에 FBU를 PAR로보내지못하고 NAR 영역에서 FNA메시지에 FBU를담아서 NAR로전송한다. NAR은이동노드의 PAR로 FBU를보내고, 그응답인 Fback를받는다. 그리고 NAR은 PAR로배달된이동노드의데이터를받아서자신이링크로접속한이동노드에게그데이터를전달한다. Fast MIPv6는네트워크계층에서신속한이동성을지원한다. 그러나보다실현가능한 Fast 핸드오버를지원하기위해서는 L2에서의 L2 핸드오버가고려된이동감지가효과적으로지원되어져야한다. 4.2.2 Hierarchical Mobile Ipv6 mobility management (RFC 4140) HMIPv6는이동노드의이동을지역적으로관리함으로써이동노드의핸드오버로인한 Signaling의양을줄여주는프로토콜이다. HMIPv6는 MAP (Mobility Anchor Point) 라는새로운구성요소를정의하고도메인레벨의 CoA와링크레벨의 CoA를정의하였다. 도메인레벨의 CoA는이동노드가 MAP 도메인의 Prefix를기반으로생성한 CoA로써 Regional CoA 라고한다. 링크레빌의 CoA는액세스라우터의 Prefix를기반으로생성한 CoA이며, on-link Care-of Address (LCoA) 라고한다. 이동노드는생성한 RCoA와 LCoA를 MAP에등록하고 RcoA를자신의 HA와상대노드에게등록한다. 만약이동노드가한 MAP 도메인내의액세스라우터간이동을하였다면, 이동노드는 LcoA를생성하고 MAP 도메인이변경되지않았으므로새로운 RcoA는생성하지않는다. 그러므로이동노드의 MAP 도메인내의이동은이동노드와 HA, 상대노드간의 Signaling을줄여준다. 그림 2 HMIPv6 의동작과정 18
HMIPv6에서는이동노드의이동을두가지로나눈다. 하나는한 MAP 도메인내에서액세스라우터간이동을했을때를가리키며, 이것을 Micro Mobility 핸드오버라고말한다. 다른하나는이동노드가한 MAP 도메인에서다른 MAP 도메인으로이동하였을때를가리키며이것은 Macro Mobility 핸드오버라고말한다. HMIPv6는이동노드가 Micro Mobility 핸드오버를수행하는경우에중점을맞추고있다. 그림 2와같이, HMIPv6에서이동노드가새로운 MAP 도메인으로진입하였을때, 이동노드는새로운액세스라우터로부터 RA 메시지를수신한다. 이동노드는 AR의 Prefix를기반으로 LcoA를생성하고, AR은이동노드의 LcoA에대한 DAD를수행한다. LcoA 주소는이동노드가 AR로이동할때마다새롭게생성된다. 그리고이동노드는 RA메시지의 MAP option에포함된 MAP의 Prefix를기반으로새로운 RcoA 를생성한다. RcoA 주소는이동노드가다른 MAP 도메인으로이동하기전까지변경되지않는다. 이동노드는 RcoA와 LcoA를생성한후, 두주소를포함한 LBU(Local Binding Update) 메시지를 MAP에게보낸다. MAP은 LBU메시지를수신한후, RcoA 주소에대한 DAD 검사를수행한다. MAP은이동노드의 RcoA주소가도메인내에서유일함을확인한후 MAP은자신의 Binding Cache에이동노드의두주소를저장한다. 이후, MAP은 MIPv6에서이동노드의 HA가이동노드의 HoA와 CoA에대하여 Proxy를수행하는것처럼, Proxy Neighbor Advertisement 메시지를이용하여이동노드의 RcoA로도다달하는패킷들을가로채어이동노드의 LcoA로터널링하여전달한다. MAP가이동노드의 RcoA와 LcoA를 Binding Cache에저장한후, 이동노드는자신의 HA에게위치등록을하기위하여 Binding Update 메시지를보낸다. Binding Update 메시지를전송하는데이때목적지주소는이동노드의 RcoA가된다. MAP은이동노드의메시지를가로채어이동노드의 LcoA로패킷들을터널링하여전달한다. HA와의위치등록이완료된후, 이동노드는상대노드들에게위치등록을할수있게된다. 4.2.3 Mobile IPv6 Fast Handover for 802.11 Networks (RFC 4260) FMIPv6는 MIPv6에서야기되는긴핸드오버지연시간을줄이기위해하부계층 (e.g., 링크계층 ) 의도움으로 L2나 L3핸드오버이전에새로운 CoA를등록하고, 기존 AR과새로운 AR과의터널링을통해 IP 연결성을보장해줄수있는프로토콜이다. 본 RFC 4260에서는 IEEE 802.11 네트워크기술에서제공하고있는 L2 핸드오버와 FMIPv6의 L3핸드오버기술이연동되어어떻게동작하는지에관해언급하고있다. 특히, 본문서에서는 IEEE 802.11 환경에서야기될수있는시나리오에따른 FMIPv6의동작과정을보여주고있다. 먼저 IEEE 802.11에서제안하고있는 L2 핸드오버기술을자세히알아보도록한다. 일반적으로, 802.11 핸드오버는하나의 AP에서다른 AP로기존의연결을변경 (so-called re-association ) 할때수행되며, 이과정은다음과같은단계로구성된다. 0. STA (mobile Station) 이이동함에따라현재연결설정된 AP로부터전파전송환경이악 19
화될때 STA는핸드오버수행의필요성을인지하게된다. 1. STA는현재사용가능한 AP들을조사 (scan) 한다. STA에의해조사된결과는사용가능한 AP들의리스트가될것이고, 각 AP들의신호강도를비롯한물리계층의정보들이포함될수있다. 2. STA은사용가능한 AP들중가장적합한 AP를선택하고, 선택된 AP들과의물리계층과 MAC 계층과의시간적동기를맞추기위해시도한다. 3. STA는새로이선택된 AP와인증과정을시도하며, 이때 AP가 Open System 방식의인증시스템을지원할경우, AP와 STA는 two-way 방식의 message 교환을수행한다. 4.STA는새로운 AP에게 association과 re-association을요청한다. STA가 AP와 reassociation 과정을수행하는경우, AP는 STA에게현재서비스중인 AP의 MAC 주소를요청하고, 일반적인 association은이를요청하지않는다. 5. L2 핸드오버과정에서 IEEE 802.11i 표준을지원한다면, STA는 AP사이에 Step 3에서 802.1x EAP-on-LAN 절차가수행될것이다. 6. 새로이연결설정된 AP는 STA에게로컬 LAN 상으로 Layer 2 Update 프레임을보내서, 연결된 Ethernet bridge의 table을 Update 시킨다. 한편, FMIPv6 핸드오버는아래와같은메시지교환방식으로구성된다. a. MN는이웃 AR들을찾기위해 RtSolPr 메시지를보낸다. b. MN는현재사용가능한이웃 AR과 AP들의정보들 (AP-ID, AR-Info) 을포함한 PrRtAdv 메시지를수신한다. c. MN는이전에현재연결된 AR (PAR) 에게 FBU 메시지를보낸다. d. PAR은새로운 AR (NAR) 에게 HI (Handover Initiate) 메시지를보낸다. e. NAR은 HAck(Handover Acknowledge) 메시지를 PAR에게보낸다. f. PAR은새로운링크를사용하여 MN에게 Fback 메시지를보낸다. g. MN는새로운 NAR로이동한후, NAR에게 FNA 메시지를보내어핸드오버절차를종료한다. 다음은본문서에서고려하고있는시나리오에관하여설명한다. 각시나리오는앞서언급한 802.11의 L2 핸드오버과정의단계번호와 FMIPv6 수행과정에서언급한단계번호를참조한번호들의순서에따라시나리오가구별된다. 20
A. 시나리오 1abcdef23456g 이시나리오는 FMIPv6 표준에서 Predictive Mode 에해당하는것으로써, MN이 L3 핸드오버이전에주기적으로 802.11의 scan 기능을수행하고, FBU 메시지를전송하는것을의미한다. 본시나리오에서는 FNA 메시지만이 L3 핸드오버수행후에전송된다는것에주목한다. 본시나리오의동작절차는시나리오이름과같이 802.11의 L2 핸드오버에서 Step 1과 2 사이에 FMIPv6의 L3 핸드오버가수행되고, L2 핸드오버가끝나는 Step 6이수행된후, FMIPv6의 Step g인 FNA를전송하게된다. B. 시나리오 ab123456cdefg 시나리오 ab123456cdefg는 FMIPv6 표준에서 reactive mode 에해당하는것으로써, 802.11 의 L2 핸드오버가수행완료된후 FMIPv6가동작하는방식이다. 여기서 FMIPv6의 ab는단지이웃 AR과 AP들의정보를얻기위해수행되는과정이며, 특히 MN이새로운서브네트웍으로이동하였을때 FNA (FBU를동반 ) 을보내기위해수행된다. C. 시나리오 123456abcdefg 시나리오 123456abcdefg는 MN이 L2 핸드오버실행이전에 NAR에대해어떠한정보도얻을수없는상황으로써, FMIPv6 표준에서정의하고있는완전한 reactive mode 이다. 본시나리오에서는핸드오버수행이후, NAR의 RA 메시지를통해 NAR과해당 AP의정보를얻게되며 FNA는 FBU를동반하여핸드오버수행이후, 즉각적으로전송될수있다. 본시나리오에서는핸드오버이전에 NAR의정보를얻을수없는상황이거나, 시나리오 B에서 PrRtAdv 메시지수행후알수있는 NAR들의정보가무수히많아서적절한 NAR을선택할수없는상황이될수있다. 본시나리오에서는 L2 핸드오버수행이끝난후, NAR에대한정보를 FMIPv6의수행중에알수있거나다른형태의기술을통해 NAR에대한정보를알수있을것이라는가정하에서 FMIPv6가수행된다. 4.3 WG Internet Drafts 본절에서는현재 MIPSHOP WG에서표준화진행중인 Internet Draft들에관하여간략히설명한다. 4.3.1 Mobile Ipv6 Fast Handovers over IEEE 802.16e Networks 본문서는 IEEE 802.16(e) 상에서 FMIPv6의동작시나리오에관한내용을담고있다. 특히, IEEE 802.16(e) 표준에서제안하고있는 L2 hard 핸드오버시에전송되는 Message들과 IEEE 802.21에서정의하고있는 L2와 L3 레벨간의핸드오버지원을위한 Triggering 메시지들을기반으로 FMIPv6 핸드오버수행의구체적인세부절차에관해언급하고있다. 21
다음은본문서에서사용하고있는 IEEE 802.16(e) 의 L2 핸드오버관련메시지들의간략한용어설명이다. MOB_NBR-ADV IEEE 802.16e Neighbor 광고메시지, 주변 BS의정보를 Serving BS가주기적으로광고 MOB_MSHO-REQ MN이 BS에게 IEEE 802.16e 핸드오버요청메시지 MOB_BSHO-RSP BS가 MN에게 IEEE 802.16e 핸드오버응답메시지 MOB_BSHO-REQ BS가 MN에게 IEEE 802.16e 핸드오버요청메시지 MOB_HO-IND MN가 BS에게 IEEE 802.16e 핸드오버실행하도록하는메시지 BSID IEEE 802.16e BS ID 다음은 IEEE 802.21에서제안된 L2에서 L3 계층으로전달되는 Triggering 이벤트들의간략한용어설명이다. New_BS_Found (NBF) New BS가발생되었을시발생되는 L2 트리거 Link_Going_Down (LGD) 공 L2 링크가끊길것이라고알려주는 L2 트리거 Link_Up (LUP) New BS와 L2연결을성공했을경우발생하는 L2 트리거 Link_Switch (LSW) New BS와링크를교환시발생하는 L2트리거 IEEE 802.16e 기반의 FMIPv6 작동과정을설명하기전에, IEEE 802.16e 표준에서제안하고있는 L2 레벨의 hard 핸드오버과정을앞서언급한 IEEE 802.16e의핸드오버수행메시지들을가지고간략히설명한다. IEEE 802.16e를지원하는 MN은자신이속한기지국으로부터주기적으로광고되는 22
MOB_NBR-ADV 메시지를수신한다. MN은 MOB_NBR-ADV 메시지를통해인접기지국들의 ID 의목록을획득하고스캐닝을통해취득한실시간링크정보를바탕으로적절한기지국을선택한다. MN은 Serving BS로부터제공되는서비스품질과신호세기등을비교하여핸드오버가가능한기지국들의리스트를 MOB_MSHO-REQ에실험기지국에게전송하고기지국은그중추천하는기지국들의리스트를 MOB_BSHO-RSP 메시지에포함하여회신한다. MN이 MOB_BSHO-RSP를수신하고목적지기지국을결정했다면, Serving BS에게 MOB_HO-IND 메시지를보내어핸드오버를최종적으로통지하고곧바로핸드오버를실행한다. MOB_HO- IND를전송한시점부터단말은 Serving BS를통해더이상데이터를송수신할수없으므로새로운네트워크로이동한후가능한신속하게 Re-entry 절차를수행해야한다. 다음그림에서본문서에서제안하는 IEEE 802.16e 기반 FMIPv6의동작과정을보여주고있다. 그림 3 IEE 802.16e 기반의 FMIPv6 수행절차 위의그림과같이, BS는주기적으로 MOB_NBR-ADV 메시지를주기적으로광고하고, MN이이를받아서적절한기지국을선택하고결정한다. MN은 L2의 NBS (New_BS_Found) 을 L3에게 Triggering하고 RtSolPr 와 PrRtAdv 메시지를 PAR과교환하고 AR Discovery 과정을수행한다. 이후, MN는 MOB_MSHO-REQ와 MOB_BSHO-RSP를교환한후, L2 핸드오버를시작한다. MN 이 L2 핸드오버의시작메시지를수신할경우, L2는 L3에게 Ling_Going_Down Triggering 이벤트를발생시키고, L3가 Link_Going_Down 메시지를수신하면, MN는 PAR과 FBU, FBAck를교환하고 PAR은그사이에 NAR과 HI, HACK를이용하여터널을생성한다. MN은 PAR에게 MOB_HO-IND를보내실제핸드오버의수행을알리고, MN은대상 BS로의핸드오버를수행하고, 802.16e의 802.16e 네트워크엔트리절차를수행한다. 802.16e 핸드오버과정이끝나 23
면, L2는 Link_UP 메시지를 Triggering 하고 MN은 FNA를 NAR에게전송한다. 마지막으로, NAR이 MN으로부터 FNA를수신하면버퍼링된데이터를 MN에게전송한다. 4.3.2 Mobile IPv6 Fast Handovers for 3G CDMA Networks 본문서는 3G CDMA 네트워크환경에서 FMIPv6 수행시나리오에대해설명한다. 3G CDMA 에서는기존의무선접속기술에서제공하는 L2 핸드오버방식과달리, Access Network 기반의 hard 핸드오버가수행된다. 다시말해서, Pilot channel들을이용하여 BS들의신호강도및 Air Interface의정보들을수집하고, MN와의협상을통해 Network이핸드오버수행을결정하게된다. 일반적으로 3G 네트워크에서는 MN이아닌 Network기반의핸드오버가수행되기때문에 FMIPv6의 Predictive Mode 방식이적용될수있다. 그러나, Network가 NAR에대한정보를 RtSolPr/PrRtAdv 메시지교환에의해알수없을경우, 3G CDMA 네트워크에서 FMIPv6는 Reactive Mode 로동작하게된다. 특히, 3G CDMA 네트워크에서는핸드오버수행을위한링크정보를 Handover Assist Information 이라고정의하고, 기존의 FMIPv6 표준에서정의하고있는 New AP Link Layer Address (LLA) 을확장하도록권고하고있다. 이는 3G 네트워크에서는 AP방식이아닌, BS의 Sector별 Pilot Channel에의해링크계층핸드오버가수행되기때문이다. 또한, 본문서에서는 Selective bi-casting 방식을제안하고있다. Selective bi-casting 방식은 MN이하나이상의라디오신호를수신할수있을때, PAR, HA 혹은 NAR이 MN가해당 signal을선택적으로 bi-casting 함으로써데이터손실및핸드오버처리시간을줄일수있도록하고있다. 4.4 IETF 66th 4.4.1 회의 Agenda 1. Agenda review, Blue sheets and volunteers for taking notes and Jabber scribe 2. WG status and I-Ds update 3. Using Cryptographically Generated Addresses (CGA) to secure HMIPv6 Protocol (HMIPv6sec) 4. Authenticating FMIPv6 Handovers 5. Handover Keys Using AAA 6. Distributing a Symmetric FMIPv6 Handover Key using SEND 24
I-D: draft-kempf-mipshop-handover-key-00.txt 7. Fast Handovers for Mobile IPv6 I-D: draft-ietf-mipshop-fmipv6-rfc4068bis-00.txt 8. Hierarchical Mobile IPv6 Mobility Management (HMIPv6) I-D: draft-soliman-mipshop-4140bis-00 9. Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6 I-D: draft-arkko-mipshop-cga-cba-04.txt 10. Media Independent Handovers: Problem Statement I-D: draft-hepworth-mipshop-mih-problem-statement-02.txt 11. Design Considerations for MIH Transport 12. Supporting Media Independent Handover Protocols with GIST I-D: draft-hancock-mipshop-gist-for-mih-00.txt 13. Network initiated handovers problem statement I-D: draft-melia-mipshop-niho-ps-00 14. Transport of Media Independent Handover Messages Over IP I-D: draft-rahman-mipshop-mih-transport-00.txt 15. Symmetric-key Based IPv6 Addresses I-D: draft-narayanan-pba-01.txt 16. AR information for FMIPv6 Messages Over IP I-D: draft-zhang-mipshop-fmip-arinfo-00.txt 4.4.2 IETF 66th MIPSHOP WG 회의내용정리이번 IETF 66th MIPSHOP WG에서는 13개의 Draft 내용이발표되었다. 그중, 두발표가 FMIPv6와 HMIPv6 표준문서에대한 Updated Draft이고, 5개가 FMIPv6와 HMIPv6에서보안강화를위한 Draft이고, 나머지는대부분 IEEE 802.21 WG에서추진하고있는 MIH에서 MIPv6 연동사항에대한발표이다. 또한, Network-Initiated 핸드오버에대한문제제기에대한 Draft 발표가있었다. 발표된 Draft의제목에서부터알수있듯이, MIPSHOP에서도 FMIPv6와 HMIPv6의보안문제, 구체적으로 Handover Key에대한보안강화와관련된내용이주요이슈가되고있다. 특히, MIPv6와 IPSEC 간의연동문제에서 Handover Key의교환문제등이표준화이슈가되고있다. 25
또한, MIPSHOP WG에서는 IEEE 802.21 MIH WG에서승인된 MN의 L2 및 L3 핸드오버지원프레임워크를바탕으로 MIPv6와의연동문제를집중적으로논의하였으며, MIPSHOP에서는 IEEE 802.21 MIH 정보를전송할전송계층표준프로토콜을설계할움직임이보이고있다. 현재 MIPSHOP에참여하는많은멤버들이 802.21 WG에서활발히활동하고있으며, 802.21 MIH와 FMIPv6와의연동관련된 Draft 문서가많이제출되고있다. 이번 66차회의에서는새로운 Working Item으로승인된문서는없으며, 대부분의발표에대한논쟁이회의장에서끝나지않아 Mailing List의이슈로대체하도록하였다. 4.4.3 향후진행방향이번 IETF 66th MIPSHOP에서는현재까지제출된 Draft 중몇개의발표가있었으며, 뚜렷이결정된사항은없어보인다. 본 WG의향후진행방향은아마도 MIPv6의핸드오버 Key 분배관련된보안사항과 CGA 사용에서추가보완사항이 MIPSHOP의향후지속적인주요쟁점이될것으로예상되며, 좀더기대되는사항으로는 IEEE 802.21 MIH WG과의협력및연동관련사항이차후많은쟁점화가될것으로예상된다. 특히, IEEE 802.21에서사용될전송계층프로토콜과관련된내용은주위깊게살펴볼사항으로많은기대를하고있다. 4.5 결론본문서에서는 IETF MIPSHOP WG에대한간략한설명과현재까지완료된표준문서들과현재표준화진행중인 Internet Draft 문서들에대한내용을요약해보았다. 또한, 이번 IETF 66th MIPSHOP WG의주요 Agenda와회의내용을간략히담아보았다. MIPv6는 IP 이동성지원프로토콜로써, 향후상용화기술로이끌기위해 IETF에서활발히표준화작업이이루어지고있는기술이다. 이에 MIPSHOP WG에서는기존의 MIPv6 표준에서문제시되고있는핸드오버지연및핸드오버 Signaling 처리, 보안문제등을중점적으로보완하고이에관한사항들을표준화를진행하고있다. 본보고서를작성하면서 IETF MIPSHOP WG에서진행하고있는표준기술들과관련된 Item 들을분석하면서, MIPv6 기술에대한전반적인지식을습득할수있었고, 현재 MIPv6와관련된최근동향들을파악할수있었다. 특히, 이번 IETF 66th 회의에참가하면서표준기술이어떻게만들어지는지, IETF 표준화회의가어떻게이루어지는지에대해자세히알수있는계기가되었다. 26
5. rserpool 5.1 Reliable Server Pooling 5.1.1 Server pool의정의클라이언트가서버에접속하기위해서버풀에먼저접속하는매커니즘을연구하는 WG로서높은신뢰성의어플리케이션을지원하여서버-클라이언트간의관리와작동에대한아키텍처와프로토콜을개발하는것이주된목표이다. 이를위해다양한어플리케이션, 블록, building block, 인터페이스, 여러종류의풀링방법, 보안, 아키텍처등을정의하며, 서버접속관리, 성능요구 (failover, heterogeneous 지연 ) 등에대한연구를진행하고있다. 관련연구범위는서버풀링을이용하여서버에접속하는클라이언트가어플리케이션의이용을원할하게효율적으로할수있도록서버간에균형있고적절한활용을하도록지원하는것이다. Server pooling의방법은 pool에어떤종류의서버가있는지를추적하다가클라이언트로부터요청이들어오면클라이언트를요청된서버에접속을시켜주는식이된다. 5.1.2 Reliable Server Pooling의목적 1) 어플리케이션개발을위한시간과비용의절감 2) 세션계층에서의오차허용매커니즘의전개 3) 요구사항이급할경우, 오차허용요구없이, 주기후에 rservpool로어플리케이션의전개 4) rservpool은개발자들에게오차허용을위한 API를제공 5) rservpool은어플리케이션에기본상태의공유를위한간단한 building block을제공 5.1.3 Working group의활동영역 1) Working Group 의연구분야 a. UDP, SCTP, TCP 등의전송프로토콜지원 b. 새로운혼잡제어관리방법 c. URI 분석매커니즘같은현재작업에대한관계 1-1) 이분야에서다루지않는것 27
1 reliable multicast protocols-optional 2 서버 pool 요소간데이터의동기화 / 일관성 3 서버 pool 요소간공유정보 4 transaction failover 2) 서버 pools 에클라이언트가접속하는구체적방법 a. 지리적으로분산된서버가같은 pool 안에서존재하는 access 매커니즘 b. load balancing 이나구체적인어플리케이션할당을하는동적인클라이언트의할당을지원하는클라이언트서버 binding 매커니즘 (load balancing application specific assignment policy) c. 서버오류나, 권한변경같은경우에 client/server 의자동환경재설정 3) client/server 접속을지원하는 server pool 관리와분산서비스 a. server pool 에서버를등록하고추적을위한기술 b. node 오류를탐지, 재설정, failover 하거나서버 pool 을관리하는프로토콜 c. server pool 의핵심적인기술인클라이언트가 server pool 정보에기반하여서버에 binding 하도록지원하는분산서비스, 높은수준의유효성이필요 d. 유연한 load assignment 와 balancing 정책수단 4) 클라이언트가서비스에접속할때의상호작용을위해프록시를사용해서내부로들어가는방식 5.2 Working Group 표준문서 5.2.1 완료된 RFC RFC3237 (Requirements for Reliable Server Pooling) 클라이언트가서버로부터서비스를제공받기위해필요한서버검색과서버간이동에대한사항인 server pooling에대한표준문서이다. 내용은다음과같다. 24시간연결된인터넷에서는언제든지서비스가가능해야한다. 이를통해많은 E- business가 24시간연속된영업을하는데이러한성능을위해소유주와시스템은높은신뢰도을제공해야한다. 이를위해서는어플리케이션의높은신뢰성와유효성을제공하기위한아키텍쳐와프로토콜을사용한 server pooling이필요하다. 신뢰성있는 server pooling은이동성과실시간어플리케이션등의서비스성능을향상시킨다. Rservpool 매커니즘은서버를등록하여네트워크의기능에유연성을지원하게된다. 그리고 load balancing을통해매커니즘에 scability의조화가되게한다. 예를들어과다한트래픽과응답시간을조정하는데에는 pool status를조절하는방식을사용하게된다. Reserpool을위한요구사항은견고성, 장애극복, 통신모델, 처리용량, 전송프로토콜, 익명사용자에대한지원, 등록과해제, 이름, 이름분석, 서버선택방법, 시간요구와크기조정, 확장성, 보안요소등이있다. 이중보안요소에는기존요소와의호환, name space 서비스, 보안상태등이요구된다. 28
5.2.2 진행중인 Draft 1) Architecture for Reliable Server Pooling Server pool은같은어플리케이션기능을제공하는하나이상의서버의집합을말한다. 이서버들은 Pool Elements(PEs) 라고불린다. PEs의형태는 RSerPool 구조의첫번째종류의개체이다. 여러개의 server pool에서 PE는오차허용이나부하분산없이제공될수있다. 이 server pool은독특한인식자로구별되는데이러한 pool handle은작은도메인이아닌전체인터넷에는유효하지않다. 더군다나 handle space는고정되어있을것이라생각된다. 그래서다단계의 query는 pool handle을해결하는데는적합하지않다. Rserpool의두번째종류의개체는 Endpoint hanndlespace Redundancy Protocol(ENRP) server이다. ENRP 서버는충분히분산된오차허용을실시간으로제공하도록디자인되었다. ENRP 서버는 Pool User(PU) 을 PE에접속시키는것을허용한정보목록으로 pool handle을조절할수있다. 이정보는 IPv4/ IPv6 주소, 전송계층프로토콜의구체적설명, SCTP, TCP, UDP 같은전송계층프로토콜과관련된포트번호에대한것들이다. 각각의작동은적어도 ENRP 서버에서이루어져야한다. 모든 ERNP 서버는작동유효범위안에서정보를가진다. 2) Aggregate Server Access Protocol(ASAP) ENRP와결합된 Aggregate Server Access Protocol(ASAP) 은 IP 네트워크에서높은이용률의데이터전송매커니즘을제공한다. ASAP은 handle 기반의 IP 주소의논리적통신종단에서고립된 address 모델을사용한다. 그래서어느한쪽이오류난경우, 오류난쪽의통신종단과 IP 주소사이의 binding을효율적으로제거한다. 게다가 ASAP은완전히투명한 server pooling과부하분산을통해 pool로서각각의논리적통신목적지를확실히한다. 또한서비스에문제를발생시키지않고언제든지서버를더하거나뺄수있다. ASAP은 SCTP에서제공된네트워크레벨의모든장점을가진다. Pool Element와 Pool User를가지고있는각각의전송프로토콜은 mapping document 를수반한다. ASAP 메시지는 PE와 ENRP 서버를통과할때 SCTP를사용해야만한다. 고이동성의 server pooling은 ASAP ENRP의 2가지프로토콜의결합으로이루어진다. ASAP은주소변환, 부하분산관리, 오류관리등의사용자인터페이스를제공한다. ENRP는높은이용률의 handle 전송서비스를정의한다. 3) Endpoint Handlespace Redundancy Protocol (ENRP) Rserpool의요구와구조의기능을완성하기위해 ENRP는 ASAP과결합되어작동되도록고안되었다. Rserpool 의동작범위내에서 ENRP는저장을위한고장방지 registry service, 부기, 정보검색, 분산 pool 작동과회원정보를분산된처리절차와메시지형식으로정의한다. 4) Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace, Redundancy Protocol (ENRP) Parameters ENRP와함께 ASAP은 IP네트워크에서높은이용률의데이터를전송메커니즘을제공한다. 29
각프로토콜은메시지포멧의파라메터의여러부분을공유해서함께동작한다. 이드래프트는두프로토콜사이의공통된파라메터를설명한다. 또한포멧뿐아니라, ASAP와 ENRP 문서의각각에언급된절차와메시지도제공한다. 5) Reliable Server Pooling: Management Information Base using SMIv2 Rserpool은 reliable server pooling을제공하기위한프레임워크이다. 이문서에서는 rserpool구현에서관리목적으로접속되는 SMIv2 규격의관리정보를설명한다. 6) Reliable Server Pooling Policies 이문서는 name server와 pool user의구현을위한고려사항을포함한 Reliable Server Pooling 중에서다양한서버정책을지원하는 ENRP, ASAP과파라미터에대해설명한다. 일부정책은 pool 구성요소의동적인부하정보를사용하기도하는데이것을적응성이있는것으로사용하지않는것을비적응성으로분류한다. Pool 사용자의선택은두가지다른개체에의해수행된다. 그러므로이문서에서는패킷형식뿐만아니라각각의서버정책을구현하기위한 name server와 pool 사용자간처리절차에대한자세한설명을한다. 5.3 회의논의사항 5.3.1 회의 Agenda 1) Discussion of ASAP implementation draft-ietf-rserpool-asap-13 (Randy Stewart) 2) Comments from Genart reviewers draft-ietf-rserpool-asap-13 draft-ietf-rserpool-enrp-13 draft-ietf-rserpool-common-param-10(randy Stewart) 3) Rserpool APIs (Michael Tuexen) 4) Rsplib (Michael Tuexen) 5.3.2 논의된내용정리먼저 rserpool의 architecture에대한논의가있었다. 여기에서 Architecture for Reliable Server Pooling(draft-ietf-rserpool-architecture-13.txt) 이개괄적이고넓은범위의프로토콜에서의설명으로읽기어렵다는의견이나왔다. 그래서그룹에서는혼동이되는문서는제외하고대신에 AD들은오늘언급되는프로토콜의짧은개괄문서를쓰기로했다. 30
Rserpool의구현과데모실행에대해서는 ASAP이이미 1년전부터테스트되어오고있었다. SCTP interop은 7월말뱅쿠버에서실시될예정이었고 rserpool은그때테스트되었을것이다. Rserpool 소켓 API에대해서는현재작업중인데코드와문서사이의차이가있어더많은작업이필요하다. 다른부분을일치시키고문서를업데이트할필요가있다. AD기자들은나온지오래되어이미완료되었어야할많은작업이있는데아직도 RFC정리작업이되지않고있어그룹이제대로활동하지못하고있다고했다. 현재도 TCP mapping 이후로 architecture, comparision, address 등의작업이있는데, 앞으로는 spec에대해서작업을하고다른사항들에대해서는중지를요구했다. 참가자들또한업데이트와 demo가필요하고미리 draft가공개되지않아활동이힘들다고했다. 이러한점을강조하기위해선언이개정될필요가있다. 그리고그룹의방향은현재의작업을마무리하고핵심프로토콜문서로이동하는것이었다. 문서목록에작업을수행하기위한사람들의신분과해야할작업이신청되었다. 의장은이러한변화들에기반한새로운이정표로개정된선언에따라작업할것이다. 그구조문서로대체될문서의목록은다음과같다. Draft-ietf-rserpool-asap-13.txt Draft-ietf-rserpool-common-param-10.txt Draft-ietf-rserpool-enrp-13.txt Draft-ietf-rserpool-threats-05.txt 그외의다른문서들은핵심문서에들어가지않고나중에작업될것이다. 5.3.3 향후진행방향정리 Rserpool WG은이번표준화회의에서는많은성과를얻지는못했다. 발표내용도많지않았던데다가발표자였던 Randy Stewart와 Michael Tuexen 에대해 AD 들이 WG의진행이더디다고불평을늘어놓았고발표자들은자신들도신경을쓰고싶으나시간이너무부족해서할수가없다는변명을늘어놓았다. 그렇지만기존문서를대체할새로운문서제작이시작된다는점에서다음 67회회의에서는진전이있을듯하다. 31
6. dccp 6.1 서론지난 7월캐나다몬트리올에서개최된 IETF 66차회의에서는차세대수송계층프로토콜표준인 DCCP(Datagram Congestion Control Protocol) 관련표준제정작업이진행되었다. DCCP 는인터넷실시간멀티미디어응용을지원하기위해기존의 TCP/UDP 프로토콜을개선한신규수송계층 (Transport Layer) 프로토콜로서, IETF 중점표준화대상기술로분류되고있다. 이에따라 DCCP 프로토콜은차후에개발되는차세대유무선통신응용서비스의하부수송계층프로토콜로써널리사용될것으로전망된다. 6.2 DCCP 개요 DCCP 프로토콜은 UDP 프로토콜에혼잡제어기능을추가한것으로써, 혼잡제어기능을통해유효전송율을높이고자개발되었다. 현재 TCP-like 방식및 TCP-Friendly 혼잡제어방식이각각 CCID(Congestion Control Identifier) 번호 2,3,4으로개발중에있다. 특히, DCCP는혼잡제어를위해유지되는연결상태 (state) 정보를활용하여, 수송계층에서의이동성지원기법등으로확장될수있다. 6.2.1 DCCP에대하여 DCCP는 UDP와마찬가지로비신뢰적전송을하지만 UDP와는달리연결설정과정과해제과정이있으며데이터송수신과정에서혼잡제어를한다. 각과정마다사용되는 packet들은상황과용도에따라조금씩다른형태를지니고있으며이 packet 형태는 9가지가있다. 모든형태의 packet에는상대쪽에게부가정보를전달하기위한옵션 (option) 이실릴수있다. 또한모든 DCCP의연결에는 DCCP가동작하는데필요한여러특성값인 feature들이존재한다. 먼저 DCCP 연결설정과해제에대해알아본후, DCCP의 9가지 packet 형식과, option과 feature들에대해알아보겠다. 그리고마지막으로 DCCP에쓰이는혼잡제어기법에대해다루겠다. 6.2.2 DCCP 연결설정과해제 1) 연결설정과정 DCCP의연결은두개의 half-connection 단위로이루어진다는점과연결설정시여러특성값들에대한협상이이루어진다는점이가장큰특징이다. 협상되는 feature중 CCID는혼잡제어메커니즘에대한선택값이고이값에따라메시지송수신과정에서사용되는혼잡제어방식이달라진다. 이제어메커니즘에따라메시지송수신과정이달라지고사용되는 feature들도달라진다. 32
연결설정과정은클라이언트의 connect() 함수에서 DCCP-Request packet을보내면서시작되고서버의 accept() 함수에서 DCCP-Response packet을보내어응답한다. 다시 connect에서는서버의응답 packet에대해 DCCP-ACK packet을만들어보내고연결설정을끝낸다. 이과정에서몇몇 feature들에대한협상이이루어지며세번의 Packet 교환과정에서협상이끝나지않는다면협상이끝날때까지 ACK Packet을주고받는다. 그림 1. SCTP 프로토콜구조 2) 연결해제과정연결해제과정은응용계층의 close() 와 shutdown() 에의해이루어지며둘중에어느것을사용해도상관없다. 해제과정에서사용되는 Packet은 DCCP-CloseReq, DCCP-close, DCCPreset이며서버와클라이언트가보낼수있는 packet 타입은정해져있으나어느쪽에서든먼저해제를시작할수있다. 서버가먼저해제를시작하는경우와클라이언트가먼저시작하는경우의과정은다음과같다. 33
6.3 Session Agendas and Presentations 6.3.1 Faster Restart 현재의 ns-2(2.28) TFRC의구현은 RFC 3448과같이동작하지않는다. NS2에서와 RFC3448 사이에는다음과같은차이점이있는데이는다음과같은상황을고려하지않았기때문에발생한다. 첫번째는 send쪽 application이 idle한상황에서도보낼 back log 데이터들이버퍼에있다는것이다. 그리고 sender는이런 back log 에기초하여 sending rate를조절한다는것이다. 이것을해결하기위해서는 small packet을전송하고이것을두번보낼동안에큰사이즈만큼전송을하는방안이고려된다. 6.3.2 TFRC Media and User Guide DCCP User Guide draft-ietf-dccp-user-guide-03.txt는응용프로그램에서어떻게 DCCP를사용할것인가에대해서이야기하였다. IETF-62차회의에서는 USER-GUIDE API관점과 Media issue관점으로두부분으로분리하였다. Media issue쪽은 draft-ietf-dccp-tfrc-media-01.txt draft로새롭게제안되었다. API쪽에서는 API 중심적으로다시쓰여질필요가있다. TFRC쪽은구현을기다리고있다. 6.3.3 DCCP Implementation Linux Kernel 2.6.14에서는 ccid3만가지고 release되었다. 이후에 ccid2를포함하였다. 현재 fast restart와 VOIP와같은것은포함하지않고있다. 현재 RFC에는완벽하지않고구현상에여러가지 bug를가지고있다. Kernel-2.6.19는개선된 ccid-2를탑재할것이다. 현재구현된 DCCP가 TCP와 congestion control과같은상황에서 fairness 하게동작하는지점검할필요성이있다. 현재테스트된것은다음과같다. FREE- BSD 와 LINUX와의동작, 브라질과뉴질랜드사이 (18hop) 에서의테스트, 다양한상황에서의테스트하기위해 NETERM사용하였다. 34
6.3.4 RTP over DCCP Implementation TFRC는 RTP stack위에 application에서구현하였다. 고효율의 video application 은작은 packet interval을가진다. 현재 TFRC를이용했을때비디오응용에서좋은 Performance를보이고있다. 6.3.5 DCCP Mobility DCCP 연결안에서여러주소바인딩과 re-binding 을제공하기위해서제안되었다. 이것은 Multi-homming과 mobility를위해사용되어진다. draftkohlerdccpmobility02.txt 에의해기술되어져있다. Mobility issue를 transport계층에서사용하려는의도는 wireless LAN은짧은거리에서이용되어지고여러 access interface는동시에사용가능하다는것에서착안되었다. 그리고 transport위에 multi-homing은다음과같은특징들이있다. End host간의 multihoming을지원하기위해서 ipv4과 ipv6간에원할한지원, 하나의 connection 안에서여러 path를제공한다. 각각의 path는서로간에데이터흐름에영향을미치지않는다. 대부분의서버의위치는고정되어있다. 위에같은이유에서 DCCP에서 mobility를제공하기위해서 SCTP와같은 protocol level에서의구현, with hip, with shim6, mobile IP와의사용과같은것을고려하고있다. 6.4 전망현재의 DCCP가 Internet-draft문서에서점진적인발전을거듭하여전송계층의다른프로토콜처럼표준프로토콜이된다면근본적인혼잡제어를하는실시간전송에적합한프로토콜로서많은응용에서사용하게될것이다. DCCP(Datagram Congestion Control Protocol) 는문제점이수정이되고부분적인업데이트가이루어지는상황이다. 시간이지남에따라 SCTP 보급이확대되면, 기존에 TCP를통해제공되던응용들도 SCTP를통해보다효율적으로제공될수있을것으로전망된다. 7. 결론지금까지본문서에서는제 66회 IETF 회의의 Working Group중 5개 WG에대해알아보았다. 각분야별 WG에대한간략한설명과함께현재까지완료된표준문서들과표준화가진행중인 Internet Draft 문서들에대한내용을정리했고각 WG의주요 Agenda 및회의내용과앞으로의전망까지정리했다. IETF Chair가보고한이번 IETF Meeting의참가인수는 44개국 1,236명이었다. 국적을보면미국의참가자가절반이었고, 중국으로부터의참가자가증가하고있던것이특징적이라고할수있다. 세계최고의인터넷망과사용자층을가지고있는우리나라이지만, IETF와같은국제표준화회의에서한국이주도적인목소리를내는것은그동안힘들었다. 이번 66 회회의에서한국인최초로 박수홍 선임연구원이 16ng WG의의장을맡게되었는데이를시작으로한국이국제표준화회의에서좀더영향력을행사할수있게되기를바란다. 35