1 / 40

차세대 인터넷 환경에서의 QoS 적용 방안 연구

차세대 인터넷 환경에서의 QoS 적용 방안 연구. 숭실대학교 네트워크 연구실 고석갑 (softgear@dcn.ssu.ac.kr). 연구목표. 인터넷 환경에서 QoS 기술 연구 및 활용방안 연구 IPv6 환경에서 자원예약 프로토콜에 의한 데이터 전달기능 개발 Linux 환경에서 IPv6 지원 RSVP 라우터 구현. 연구결과. Linux 환경에서 서비스의 공정성을 위한 WF 2 Q+ 스케쥴러 연구 , 구현 IPv6 환경에서 QoS 제어를 위한 메커니즘 연구 , 개발 , 구현

ingrid
Download Presentation

차세대 인터넷 환경에서의 QoS 적용 방안 연구

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 차세대 인터넷 환경에서의QoS 적용 방안 연구 숭실대학교 네트워크 연구실 고석갑 (softgear@dcn.ssu.ac.kr)

  2. 연구목표 • 인터넷 환경에서 QoS 기술 연구 및 활용방안 연구 • IPv6 환경에서 자원예약 프로토콜에 의한 데이터 전달기능 개발 • Linux 환경에서 IPv6 지원 RSVP 라우터 구현

  3. 연구결과 • Linux 환경에서 서비스의 공정성을 위한 WF2Q+ 스케쥴러 연구, 구현 • IPv6 환경에서 QoS제어를 위한 메커니즘 연구, 개발, 구현 • IPv6환경에서의 자원예약 프로토콜 연구, 개발, 구현 및 시스템 시험 • 논문 • Linux 상의 IPv6 지원 Inteserv 라우터 구현 및 성능분석 • 소프트웨어 등록 • 수락제어부, 트래픽 제어부(TC), WF2Q+스케쥴러, IPv6 RSVP데몬

  4. Integrated Service • Introduction • Integrated Service Architecture • RSVP(Resource ReserVation Protocol) • RSVP Optimization

  5. Introduction • Playback Applications packet arrive packet generation Buffer Sequence number Network delay Playback Time

  6. Introduction(cont.) • Integrated service model • Guaranteed service • controlled load service • best-effort service • Protocol support • RSVP(Resource reservation protocol) • Algorithms • scheduling • admission control

  7. Introduction(cont.) • Service Class • Guaranteed service : hard real-time • guarantee a deterministic upper bound on delay for each packet in a session provided that the session does not send more than it specifies • admission control based on worst-case analysis • per flow queueing support at routers • Controlled load service : soft real-time • provide a flow with a QoS closely approximating the QoS that the same flow would receive from an unloaded network • measurement based admission control possible • scheduling for aggregate possible

  8. Integrated Service Architecture • Integrated service 망 구성 Host A 1) Host B 2) Host 3) Edge Router Core Router 1) RSVP PATH message 전송 : traffic 특성 전송 2) RSVP RESV message 전송 : 경로 내의 모든 노드간의 down-link 자원을 예약 3) QoS 보장된 경로를 따라 데이터 전송

  9. Integrated Service Architecture(cont.) HOST ROUTER RSVP daemon RSVP daemon RSVP Application Routing Protocol Daemon Policy Control Policy Control Admission Control Admission Control Packet Scheduler Classifier Classifier Packet Scheduler data

  10. RSVP • Role of RSVP in the architecture • Signaling protocol for establishing per flow state • Carry resource request from hosts to routers • Collect needed information from routers to hosts • At each hop • consults admission control and policy module • sets up admission state or informs the requester of the failure

  11. RSVP(cont.) Example of RSVP basic operation 1. Path_msg S1 2. forwarding Path_msg R1 R2 D1 S2 R3 3-1.Resv_msg 4. forwarding Resv_msg D2 3-2. Resv_msg

  12. RSVP parameters for IntServ • Guaranteed Service Tspec • p : peak rate(bytes/s) • b : token bucket size(bytes) • r : token generation rate(bytes/s) • m : minimum datagram size(bytes) • M : maximum datagram size(bytes) Rspec • R : bandwidth(bytes/s) • S : slack term(ms) • Controlled-Load Service Tspec • p : peak rate(bytes/s) • b : token bucket size(bytes) • r : token generation rate(bytes/s) • m : minimum datagram size(bytes) • M : maximum datagram size(bytes)

  13. RSVP-PATH Message • Sender Template : a filter spec identifying the sender • whether to forward a RESV message to this sender • shared explicit, fixed filter styles • Sender Tspec • Describes data traffic generated by a sender • Never modified in the network • Adspec object • Describes services and parameters of the path • May be updated by network elements

  14. RSVP-RESV Message • FLOWSPEC object • Tspec • Describes the traffic flow desired • Rspec • Parameters required to invoke the desired service • Transmitted upstream to intermediate network nodes and senders • May be merged at intermediate network nodes

  15. One Pass With Advertising (OPWA) • Improvement over basic model • Motivation • collect information along the path so that receivers can make better reservation request • Optional Adspec object in PATH message • Default General Parameters fragment • Service specific fragment such as Guaranteed service or Controlled load service fragment

  16. ADSPEC Usage • Sender initialized • At each network element • Each service updates its section of ADSPEC • Break bit is set if the service is absent • General parameters break bit is set if a non-RSVP hop is on the path • Services may override general parameters • Receiver discovers whether RSVP is fully supported and what services are available

  17. Soft State • Per session state has a timer associated with it • path state, reservation state • State lost when timer expires • Sender/Receiver periodically refreshes the state, resends PATH/RESV messages, resets timer • Claimed advantages • no need to clean up dangling state after failure • can tolerate lost signaling packets • signaling message need not be reliably transmitted • easy to adapt to route changes • State can be explicitly deleted by a Teardown message

  18. Linux 상의 IPv6지원 Intserv 라우터 구현 • 개요 • Intserv 라우터 구조 • 리눅스 트래픽 제어부 구조 • WF2Q+패킷스케쥴러 구현 • RSVP지원 라우터 구현 • 실험 및 성능분석

  19. 개요 • 인터넷수요 양적 증가  IPv6 • 서비스 품질 보장  종합서비스모델,RSVP • 리눅스 환경에서의 Intserv라우터 구현 미비(CBQ only, non-configurable) • WF2Q+, RED 이용 IPv6지원 Intserv라우터 구현

  20. Intserv 라우터의 구조 RSVP signal 라우팅데몬 RSVP 데몬 수락제어/정책제어 User Level Kernel Level IP Forward 패킷스케쥴러 패킷수신부

  21. RSVP 라우터 구현 • 커널내 WF2Q+패킷스케쥴러 구현 • Linux Traffic Controller Interface 호환 • RED, TBF 등 적용가능 • 기존 ISI의 RSVP 코드 사용 • 기존 코드 Admission Control 부분 수정 • Config file 이용 설정가능 • WF2Q+ 위한 인터페이스 • TC_init, TC_AddFlowSpec, TC_DelFlowSpec, TC_AddFilter, TC_DelFilter • IPv6를 위한 수정 • 기존코드 버그수정 및 포팅

  22. Linux Traffic Controller • Components • Queue Discipline • Class • Sources • /usr/src/linux/net/sched/ • /usr/src/include/net/pkt_sched.h • Filter • Policing enqueue dequeue

  23. Queue Discipline in Linux • 주요함수 • enqueue • dequeue • requeue • drop • init • reset • destroy • dump wf2q_enqueue wf2q_dequeue wf2q_requeue

  24. Class & Filters in Linux • Class functions • graft, get, put, change, delete, walk, tcf_chain, bind_tcf, unbind_tcf, dump_class • Filter functions • classify, init, destroy, get, put, change, delete, walk, dump

  25. WF2Q+ Packet scheduler 2 3 1

  26. WF2Q+ Packet scheduler구현 struct wf2q_class // 각 세션별 데이터 구조체 { u32 classid; /* classid */ unsigned int rate; /* service rate */ unsigned long stag; /* virtual start time of this class */ unsigned long ftag; /* virtual finish time of this class */ .... }; struct wf2q_sched_data // 스케쥴러 자체, 공통 데이터 구조체 { unsigned long virtualtime; /* system virtual time */ unsigned long w; /* total traffic in dt */ unsigned int sum_rate; /* summation of rates of all classes */ ... };

  27. enqueue()

  28. dequeue()

  29. TC_acdb : Admission Control Database • 초기설정파일 적용을 위하여 acdb구조체 정의 • acdbase[]: 설정파일 ac.conf을 읽어 그 내용을 저장 • currentbw[]: 현재 예약된 량을 저장 structacdb{ char dev[255]; /* interface device name */ float bw; /* total Bandwidth, Mbps */ char qname[255]; /* Q discpline name */ float gx; /* Bandwidth for Guaranteed Service */ float cl; /* Bandwidth for Controlled Load Service */ float be; /* Bandwidth for Best Effort */ } currentbw[INF], acdbase[INF]

  30. 수락제어 알고리즘: 수정가능(TC_AddFlowspec) • 예약요구시 호출 • 서비스 종류(부하제어형/보장형)에 따른 수락여부결정 • 수락결정 후 자원예약 • 서비스율 조정 • currentbw[]조정 추가적인 BW+currentbw <= acdbase ? tc_change_rate() currentbw[OIf].cl+= req_bw; rh->ai.rate= req_bw

  31. TC_AddFilter • 예약요청수락시 호출 • 트래픽제어부에 필터를 삽입 • RTNETLINK를 이용한 삽입요청 • style(FF,SE,WF)에 따라 다른 형태의 필터생성 가능 (현 구현에서는 목적지 주소/포트로 생성) • 삽입 성공한 필터의 핸들을 예약핸들에 저장 • 필터삭제시 사용

  32. IPv6지원 위한 수정 • 링크인터페이스에 연결된 IP주소 얻어냄 • Router Alert Option세팅 • 수신대기 • 수신시 • 패킷수신처리 • 송신시 • 송신패킷에 Router Alert Option헤더 삽입 • 패킷송신

  33. RSVP Filter 구조체 • RSVP_DST_LEN은 1 또는 4 structrsvp_session { structrsvp_session *next; u32 dst[RSVP_DST_LEN]; // 목적지 주소 structtc_rsvp_gpi dpi; // 포트번호 u8 protocol; // TCP? UDP? structrsvp_filter *ht[16+1]; }; structrsvp_filter { structrsvp_filter *next; u32 src[RSVP_DST_LEN]; // 송신자 주소 structtc_rsvp_gpi spi; // 포트번호 structtcf_result res; }

  34. 실험환경 CL1:2M CL2:1M

  35. 예약전 Traffic • RSVP에 의한 예약이 이루어지기 전 상태 • BE 트래픽에 의해 GX,CL트래픽 서비스를 받지 못함

  36. 예약후 Traffic • RSVP메시지를 통해 예약이 이루어진 상태(WF2Q+동작) • BE에 의해 예약된 트래픽이 영향을 받지 않음  품질보장

  37. 예약량을 초과한 트래픽 • 예약한 양을 초과하여 GX트래픽을 전송하였을때 • 약정된 이상의 트래픽은 보장되지 않음

  38. Scheduler Overhead 측정:세션수 증가에 따른 RTT • 세션수 증가에 따른 지연시간의 증가가 크지 않음.

  39. RED 적용 실험 • RED를 적용시 패킷손실율 • 확률적인 패킷손실을 보임 • Global Synchronizarion 회피가능 패킷손실율 시간(초)

  40. 결론 • IPv4,IPv6환경에서 동작하는 RSVP품질보장 라우터 구현, 성능 확인 • 예약성립시 대역폭보장 • 세션수 증가에 따른 지연시간확인 • Router증가시 Scalability문제 확인 • IPv6환경에서의 RSVP응용 단말 개발/시험 환경 구축

More Related