| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2024

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (136)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR Mobile의 5G 특화망 솔루션 (my5G)  Updated   |   뉴젠스의 5G 특화망 구축 및 운영 서비스  NEW  

  스폰서채널 서비스란?
banner
banner
대역폭 제어: Traffic Policing
Bandwidth Control: Understanding Traffic Policing
March 23, 2012 | By 유창모 (cmyoo@netmanias.com)
코멘트 (6)
14
Traffic Policing은 대역폭을 제어(제한)하는 기술로써 다음과 같은 응용에 이미 널리 사용되고 있습니다.
  • Enterprise 서비스를 제공하는 통신 사업자가 Enterprise(기업)와 계약(SLA)된 대역폭 만큼만 패킷이 통신 사업자망으로 유입될 수 있도록 대여폭 제어 (보통 PE 라우터에서 수행)
  • Residential 서비스를 제공하는 통신 사업자가 가입자별 대여폭 제어 혹은 P2P와 같은 특정 응용에 대한 대역폭 제어 (LTE의 경우 P-GW 혹은 별도 DPI 장비가 수행), 마음만 먹으면 Smart TV로 가는 트래픽만 골라 대역폭 제어도 가능하겠죠~
 
대부분의 네트워크 장비(스위치/라우터)는 RFC 2697(srTCM; A Single Rate Three Color Marker), RFC 2698(trTCM; A Two Rate Three Color Marker) 표준를 이용하여 Traffic Policing을 구현하고 있습니다. 오늘은 이 중에 RFC 2698(trTCM) Traffic Policing 기술에 대해서 설명을 드리도록 하겠습니다. (RFC 2697/2698은 2~3페이지 밖에 되지 않으니 관심있으신 분들은 한번 읽어 보세요)
 
Introduction
Traffic Policing의 구성요소는 아래 그림과 같습니다.
 

 

  • METER: 수신 패킷(Incoming Packet)의 유입률(bps)을 측정하여,
  • MARK (COLORING): 그 유입률이 약속된 대역폭 이하이면(conformance with the service agreement), 그 패킷에 marking 후 포워딩하고(Ethernet 802.1p, MPLS EXP, IP DSCP 필드에 marking. 사실 반드시 marking을 할 필요는 없음),
  • DROP: 그 유입률이 약속된 대역폭 이상이면 패킷을 drop함
 
Two Rates & Three Colors
 

 

Two Rates - CIR & PIR
  • CIR (Committed Information Rate): 통신 사업자와 가입자(Enterprise or Residential user)간에 SLA(Service Level Agreement)를 통해 서로 합의된 대역폭(bps)으로, 통신 사업자 망은 이 대역폭(CIR) 만큼 가입자 트래픽을 guarantee해야 할 의무가 있음 (no packet loss)
  • PIR (Peak Information Rate): 수신 패킷의 유입률이 CIR 값을 넘어서더라도 망에 congestion이 발생하지 않는 선에서 통신 사업자 망에서 받아 줄 수 있는 대역폭을 PIR로 정의 (PIR > CIR). 즉, CIR 까지는 guarantee하고 CIR이 넘더라도 PIR 까지는 받아 줄 수 있으나 guarantee는 못함.
 
Three Colors - Green, Yellow & Red
  • Green: 수신 패킷의 유입률(bps)이 CIR(bps) 이하인 경우 그 패킷은 Green
  • Yellow: 수신 패킷의 유입률이 CIR 보다 크지만 PIR 이하인 경우 그 패킷은 Yellow
  • Red: 수신 패킷의 유입률이 PIR 이상인 경우 그 패킷은 Red
 
전형적인 예는 다음과 같습니다. 
어떤 Enterprise 가입자에 대해 SLA를 통해 CIR=10Mbps, PIR=15Mbps로 설정을 하였다면,
Enterprise 가입자로 부터 유입되는 트래픽에 대해서 Metering을 수행하고, "유입률이 CIR(10Mbps) 이하인 Green 패킷은 DSCP=AF로 마킹 및 패킷 포워딩하고, CIR(10Mbps)은 넘었지만 PIR(15Mbps) 이하인 Yellow 패킷은 DSCP=BE로 마킹 및 패킷 포워딩(이후 네트워크 상에 다른 라우터에서 congestion이 발생하게 되면 DSCP=BE에 해당하는 패킷은 drop 될 수도 있음)하고, PIR(15Mbps) 이상인 Red 패킷은 drop시킴"
 
 
Token Buckets
패킷의 유입률에 대한 Metering 방법으로 Token Bucket을 사용합니다. 아래 그림과 같이 2개의 Token Bucket이 있습니다.
 
Token Bucket 1 (P)
  • Token Bucket에 Token 채우기: 이 Token Bucket으로는 초당 "PIR/8"개의 Byte Token(이하 Token)이 채워집니다. 예를 들어, PIR=8Mbit/s(bps)이면 이를 byte로 환산하면 1Mbyte/s이고 즉, 초당 1M(1,000,000)개의 Token이 채워집니다. (Token 1개 = 1byte)
  • Token Bucket의 최대 Token 개수: 이 Token Bucket에는 최대 PBS(Peak Burst Size) 만큼의 Token이 들어 갈 수 있습니다. 예를 들어, PBS=8Kbyte이면 이 Token Bucket에는 최대 8K(8,000)개의 Token이 저장될 수 있는 것입니다. 그 이상의 Token은 저장 될 수 없습니다.
  • Token Bucket에서 Token 빠져 나가기: 그리고 패킷이 유입되면, 해당 패킷 크기 만큼 이 Token Bucket에 담겨 있는 Token이 없어집니다. 예를 들어, Token Bucket에 8,000개의 Token이 있고, 1,000byte 패킷(IP header 포함)이 유입되면, Token Bucket에는 7,000개의 Token이 남게 됩니다.
 
Token Bucket 2 (C)
  • Token Bucket에 Token 채우기: 이 Token Bucket으로는 초당 "CIR/8"개의 Token이 채워집니다. 
  • Token Bucket의 최대 Token 개수: 이 Token Bucket에는 최대 CBS(Committed Burst Size) 만큼의 Token이 들어 갈 수 있습니다. 그 이상의 Token은 저장 될 수 없습니다.
  • Token Bucket에서 Token 빠져 나가기: 그리고 패킷이 유입되면, 해당 패킷 크기 만큼 이 Token Bucket에 담겨 있는 Token이 없어집니다. 
 

 

이제 2개의 Token Bucket을 이용한 Two Rate Three Color Marking 과정에 대해서 살펴 보겠습니다. (간단합니다.)

  • 최초 2개의 Token Bucket은 각각 PBS, CBS 만큼의 Token으로 가득차 있습니다.
  • 이제 사이즈가 B byte인 패킷이 하나 들어 옵니다.
  • 먼저 Token Bucket 1의 현재 Token 개수(Tp)와 B를 비교합니다. 만약 B 보다 Token 개수가 적으면 이 패킷은 Red 패킷이 됩니다. (보통 Red에 해당되는 패킷은 drop이죠)
  • 그렇지 않으면 이번에는 Token Bucket 2의 현재 Token 개수(Tc)와 B를 비교합니다. 만약 B 보다 Token 개수가 적으면 이 패킷은 Yellow가 됩니다. 그리고 Token Bucket 1의 Token 개수(Tp)에서 B 만큼 뺍니다.
  • 위 두가지 경우에 해당되지 않으면 그 패킷은 Green입니다. 그리고 Token Bucket 1, 2의 Token 개수(Tp와 Tc)에서 각각 B 만큼 뺍니다.
  • 이 와중에 Token Bucket 1, 2에는 초당 PIR/8, CIR/8 개의 Token이 채워집니다.
  • 이 과정이 계속 반복됩니다.

 

Token Buckets의 동작 예

아래 그림은 Token Bucket의 동작 예입니다.

Token Bucket 1은 초당 1,000,000개의 Token이 유입되고, Token Bucket에 담을 수 있는 최대 Token 개수는 8,000개 입니다.

Token Bucket 2는 초당 5000,000개의 Token이 유입되고, Token Bucket에 담을 수 있는 최대 Token 개수는 4,000개 입니다.

 

그리고 어느 시점에...

 

Token Bucket 1에는 1,000개의 Token이 남아 있고, Token Bucket 2에는 600개의 Token이 있습니다.

 

이 상황에서

  • 1500 byte 패킷이 유입되면, Token Bucket 1의 Token 개수가 부족하므로(1500 > 1000) 이 패킷은 Red입니다.
  • 800 byte 패킷이 유입되면, Token Bucket 1의 Token 개수는 충분하고(800 < 1000), Token Bucket 2의 Token 개수는 부족하므로(800 > 600) 이 패킷은 Yellow입니다. 그리고 Token Bucket 1에서 800개의 Token을 빼게 되어 Token Bucket 1에는 200개의 Token만 남게 됩니다.
  • 300 byte 패킷이 유입되면, Token Bucket 1과 Token Bucket 2의 Token 개수로 충분하므로 이 패킷은 Green입니다. 그리고 Token Bucket 1과 2에서 각각 300개의 Token을 빼게 되어 Token Bucket 1에는 700개, Token Bucket 2에는 300개의 Token이 남게 됩니다.
 

 

이와 같은 Token Bucket을 이용한 대역폭 제어를 위해서는 아래 4개의 파라미터가 장비(스위치/라우터)에 설정되야 합니다.

   : CIR (bps), PIR (bps), CBS (byte), PBS (byte)

 

마지막으로 아래는 위에서 설명드린 RFC 2698 표준을 발췌한 것입니다.

 

 Let us assume that
   Token Bucket 1 is P
   Token Bucket 2 is C
   Tp is number of Token (Token Count) in a P
   Tc is number of Token (Token Count) in a C 
 
 Initially
   Tp(0) = PBS /* Token Count of Token Bucket 1(P) is initially full */
   Tc(0) = CBS  /* Token Count of Token Bucket 2(C) is initially full */ 

 A packet of size B bytes arrives at time t
   - If Tp(t) - B < 0, then the packet is red, else
   - If Tc(t) - B < 0, then the packet is yellow and Tp is decremented by B, else
   - the packet is green and both Tp and Tc are decremented by B

 

 

Related Video
넷매니아즈 2012-03-23 11:23:45
좀더 자세히 알고 싶으신 분들은 아래 링크 클릭하세요~*

http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/
신현 2012-03-26 15:36:00
오타가 있는 듯 합니다. 아래 "동작 예"에서...

300 byte 패킷이 유입되면, Token Bucket 1과 Token Bucket 2의 Token 개수로 충분하므로 이 패킷은 Green입니다. 그리고 Token Bucket 1과 2에서 각각 800개의 Token을 빼게 되어 Token Bucket 1에는 700개, Token Bucket 2에는 300개의 Token이 남게 됩니다.

800개의 Token이 아니라 300개의 Token 인듯 합니다.

쉬운 자료 감사합니다.
넷매니아즈 2012-03-26 15:39:04
어이쿠~ 오타네요.

수정했습니다. 감사합니다. ^^*
김상국 2015-10-11 19:37:20

유용한 자료 감사합니다...

 

궁금햐 2017-05-02 03:42:12

packet 2에서보면 bucket1에서 1000-800 해서 200 만 남는데 왜 갑자기

packet 3에서는 1000-300 이 된건지 모르겠습니다. token이 채워진 것이라면 bucket2도 token이 채워졌어야 하는 것 아닌가요

또한 채워지더라도 왜 1000 으로 채워진건지도 궁금합니다. bucke 1의 경우, 1,000,000 개가 채워졌어야 하는건 아닌지요

넷매니아즈 2017-05-12 12:26:09

Packet 1, 2, 3가 동시에 혹은 시간에 흐름에 따라 순차적으로 유입된 것이 아니고,
Token이 1,000개 있는 상황에서
만약 
Packet 1이 유입되면 Red이고
Packet 2가 유입되면 Yellow이고
Packet 3가 유입되면 Green이라는 의미입니다.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
01/13/2012
Netmanias Blog
01/06/2012
Netmanias Blog
12/30/2011
Netmanias Blog
01/10/2004
Netmanias Technical Documents
12/10/2003
Netmanias Technical Documents
View All (1207)
5G (130) 5G 특화망 (43) AI (16) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (19) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (14) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (63) KT (46) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (15) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) O-RAN (2) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) Private 5G (54) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (42) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (3) 이음 5G (24)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2023년 6월 현재 넷매니아즈 회원은 55,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호