포워딩 - 라우터에서 어떤 패킷이 들어오고, 어떤 output으로 내보낼 것인가? 데이터플레인(라우터)에서 결정
라우팅 - 이 패킷이 어디서부터 어디까지 가는데, 그 적절한 루트경로 결정. 컨트롤플레인에서 결정.
이의 전형적 방법) 각 라우터가 인터코넥션(라우팅 알고리즘)으로 테이블 채워 라우팅(pre-router control plane)
SDN은, 컨트롤플레인을 데이터플레인에서 뜯어내, 얘가 모든 정보 모아 테이블에 계산 후, 각 라우터의 Control agent에 알려줌.
라우팅 프로토콜 - 좋은 path 찾기가 목표
information이 로컬한가(디스턴트 벡터 알고리즘 중 벨만포드), 글로벌한가(링크 스테이트 알고리즘 중 다익스트라)
벨만포드 예시
Dx(z) = min{c(x,y) + Dy(z), c(x,z) + Dz(z)}
디스턴스 벡터 - 목적지까지의 거리와 목적지까지 가는 방향만을 저장하며 인접 라우터들과 주기적으로 라우팅 테이블을 교환하여 관리.
하나의 라우터가 모든 정보를 지닌 것이 아닌 이웃 라우터에게 전달받는 식이기 때문에 특정 라우터의 라우팅 테이블의 변화가 생길경우 모든 라우터가 그 변화를 받아들이기까지의 시간이 오래 걸린다.
링크 스테이트 - 하나의 라우터가 목적지까지의 모든 경로 정보를 알고 있음. SPF 트리란 가장 빠른 경로를 찾아가는 SPF 알고리즘 생성. 라우터는 트리를 이용해 라우팅 테이블을 만듦.
한 라우터가 모든 정보를 알고 있기 때문에 링크의 변화를 알아채는데 걸리는 시간이 짧고 라우터끼리의 교환이 자주 발생하지 않음. 그러나 라우터가 모든 정보를 관리해야 하기 때문에 메모리 소모가 크며 CPU의 부담이 큽니다.
AS : 쪼개는 단위, 마치 도메인.
도메인끼리의 라우팅/바깥끼리 라우팅 = 인트라/인터 AS
동일한 도메인에선 동일한 인트라도메인 프로토콜이 돔.
다른 AS끼리의 라우터는 다른 인트라-도메인 라우팅프로토콜 돌릴 수 있음.
인터AS 태스크: 날 거치면 어디로 갈 수 있는가? 를 외움
인트라AS 태스크 : IGP(인테리어 게이트웨이 프로토콜)
1) OSPF: 다익스트라 활용. TCP/UDP가 아닌 자체 IP알고리즘으로 연결. 라우터를 구조화
area-border-router가 자기 에리어로 데이터 뿌리는, 영역에 있는 라우터.
2) BGP: 2개의 서버프로토콜로 나뉨. AS-PATH라 하는, 여태 거친 PATH가 존재 & NEXT-HOP이라는, 다음 hop AS로 가게 해주는 특정 내부AS
eBGP: 게이트웨이 역할.
iBGP: 모든 인터널AS끼리를 관리
게이트웨이는 import policy라 하는, 거쳐갈 수 있는 도메인AS면 받고, 절대 가서는 안 되는 곳 포함 시 accept안하는 것 존재
핫 포테이토 라우팅 - 아무 가까운 라우터에다 던짐.
인트라AS : policy 없이, 기술적 어프로치만 함. 효과(퍼포먼스)만 따짐.
인터AS: 루트가 어떻게 결정될지, 정치적 고려도 함.
SDN : Logically Centralized 된, open 및 non-proprietary. 중앙집권적으로 계산해 라우터에 뿌리기.
요구조건을 SDN측에서 다 받아들여, 루트를 다 결정하고 내려보냄.
상하구조는
| Network-controll Application(Control plane) |
| SDN Controller(Control plane) |
| Data Plane |
와 같으며
SDN Controller은, 네트워크 스위치 & 어플리케이션의 소통의 중간.
ICMP(인터넷 컨트롤 메세지 프로토콜) : 에러 리포트 등, IP레이어에서 직접 메시지를 보냄.
링크 레이어: 링크에는, '유선/무선 링크' 존재.
어플리케이션의 단위 - 메세지. 이를 쪼개고 캡슐화한 세그먼트(4단위)
여기에 또 캡슐화하면, 네트워크 레이어의 데이터그램(3단위) 거기에 또 하면 프레임(링크레이어인 2단위)
역할:
1) framing : 프레임화 시키기(MAC 주소 판별해, 데이터그램 캡슐화시키기)
2) 신뢰할만한 전송 보장
3) 플로우 컨트롤
4) 에러 디텍션/코렉션
5) 하프-듀플렉스/풀-듀플렉스 : 단방향 통신 - 하프, 양방향 동시통신 - 풀
네트워크 어댑터에 구현됨.
패리티 체킹
1의 숫자가 짝수면 맨 마지막에 0을, 홀수면 1을 첨가. 이런 방식을 통해 1을 짝수개로 만든다.
만약 가로 세로를 다 봤는데 홀수인 부분이 있으면 거기가 문제.
그외에도 CRC비트:
보내려는 데이터 D(101110)에, 3비트의 CRC를 넣고자 하면, G(제너레이터)는 그보다 한 비트 많은 4비트를 넣는다.
이는 임의의 숫자로 정해도 되며, 이 오리지날 데이터에 3비트의 000을 넣고, G로 나눠 몫을 만든다.
그 나머지는 R비트라 칭하며, 위처럼 011이 나온다.
그러면 이를 오리지널(D)에 붙여, 101110 + 011 = 101110011을 프레임에 넣어 전송.
링크 레이어의 두 타입의 링크:
ppp : 포인트 투 포인트(전화처럼, 채널 할당)
브로드캐스트 : 공유. 콜리전 발생 가능.
멀티플 액세스 프로토콜은, 브로드캐스트의 collision 방지.
이것을 이용한 것이 MAC 프로토콜. 채널을 시간(TDMA)로 쪼개거나, 프리퀀시로 쪼개기(FDMA). 혹은 유저별 고유 코드번호로 구별(CDMA).
랜덤액세스 프로토콜 - 충돌이 일어나더라도 그냥 하자.
테이킹 턴 - 나머지
랜덤 엑세스 프로토콜 : 모든 대역폭을 하나에게 할당. 콜리전을 효율적으로 리커버.
1) 슬롯티드 알로하 : 모든 프레임을 같은 사이즈로 나누기, 한 시간단위에 한 프레임 전송. 싱크로나이제이션.
충돌나면, 확률에 의거해 보낼지 안보낼지 결정. 즉, 콜리젼 시 탈락하는 프레임은 결국 낭비.
2) 퓨어 알로하 : 싱크로나이제이션 제거. 타임슬롯이 시작될 때만 프레임 보내지 않고, 언제나 보낼 수 있음. 효율성은 감소.
3) CSMA : 채널 센싱을 통해, busy와 idle을 평가, 그에 따라 보냄.
4) CSMA/CD : 콜리젼 디텍션 시, 그냥 보내는 것과 달리 여기선 abort 통해 낭비 줄임.
MAC주소
ARP테이블이라 하는, 각 IP주소와 유니크한 맥주소를 1to1 매핑해 관리하는 것을 이용.
TTL로, 얼마나 그 데이터를 유지시킬 지 결정.
A는 B의 IP주소는 알아도 MAC주소를 모른다.
A는 자기 가장 가까운 라우터의 정보를 갖게 된다.
맥 주소로 라우터 주소가 붙으면 이는 라우터로 간다. 그럼 새로운 프레임을 만들어, 라우터가 보내준다.
이더넷 : 버스에서 현재는 스위치 통한 스타로.
이더넷 스위치는, 프레임의 포워드 및 체크.
(둘 다 store-and-forward 방식, 포워딩 테이블 활용)
라우터 - 네트워크 레이어, IP주소 확인. 라우팅 알고리즘으로 테이블 채움.
스위치 - 링크 레이어, 맥주소 확인. 러닝으로 테이블 채움.
VANS : 거리는 떨어져 있어도, 논리적으로 붙어있게 하거나 OR 붙어있어도 논리적으로는 다르게 : 버츄얼 랜
MPLS : MPLS라는 헤더에 구체적 비트 정보를 넣어, 스위치가 전송하게. '버츄얼 서킷'에서 유래됨.
src(보내는 곳)의 정보 역시 고려함으로써, flexibility를 보장.
홈 네트워크에서 dst로 가고자 함.
1) 무선랜에 연결 : DHCP 프로토콜이, 애플리케이션에서 나와 캡슐화 거쳐, 브로드캐스팅.
2) 내가 속한 랜에 DHCP가 돌고 있는 애가 그걸 듣고, 디멀티플렉싱으로 정보를 봄.
3) 이를 다시 캡슐화 해, DHCP ACK를 넣고 기타 정보를 넣어 보냄.
4) 다시 디멀티플렉싱으로 나는 유일한 IP어드레스 할당 및 가장 가까운 DNS 서버 IP주소와 first hop의 IP주소 획득.
5) 이제, 구글에 접속하기 위해 구글을 침. 그런데 난 이 구글 IP주소를 모른다.
6) 이를 묻기 위해, DNS프로토콜을 돌림. 난 유니크한 IP주소 할당되었으니, MAC어드레스로 통신. ARP 프로토콜로 MAC프로토콜(MAC주소)를 요구.
7) ARP REPLY를 통해, 첫번째 라우터의 MAC주소를 알게 됨. 이를 통해 통신 가능.
8) DNS서버로 가는 쿼리를 담은 프레임을 그 MAC주소로 알게 된 라우터로 통신, 통신... DNS서버까지 감.
라우팅 알고리즘(RIP, OSPF, IS-IS, BGP 등)을 통해 DNS서버까지 감. 그럼 DNS서버가 디멀티플렉싱으로, 알고픈 메시지를 받음. 그 해답을 보냄.
9) 이를 받았으니, 다시 웹페이즈를 요청하는 걸 구글 주소로 보냄. TCP와 연동된 HTTP로, 웹서버로 그 정보 보냄. 우선은 액츄얼한 데이터를 주고받기 전에 요청-ACK의 커넥션이 오간다. TCP니까. 다음으로 HTTP로 웹페이즈를 보여줌.
Wireless
1) 호스트(단말기)
2) base station - 마지막 one-hop. 즉 현 단말기와 연결된 최초의 스테이션. 단말기와 network infrastructure 연결시킴
3) wireless link - 모바일(단말기)와 base station을 연결시키는 one-hop.
4) infrastructure mode - base staion끼리 wired network로 연결된 상태. 즉 base station들의 중심.
handoff로, 단말기가 base station을 옮겨갈 때 그 스테이션을 바꾸는 현상.
5) ad-hoc mode - 상설되는 것이 아닌, infrastructure 없이, 어떤 목적 없이 단말들이 잠시 모인 상태. 간단한 네트워크로 통신 후, 회의가 끝나면 흩어져 사라지는 통신.
종합 - infrastructure이 있느냐 없느냐, single hop이나 multi hop이냐에 따라 다름.
wifi : single hop & infrastructure
mesh-net : multiple hop & infrastructure. 초원처럼 넓은 곳에서 적은 사람은, base station끼리 wireless 통신을 하게 함.
블루투스 : no infra & single hop. 차끼리 노드 통신해서 가는 것.
무선통신의 주요점 3개
1) 신호 세기가 감소
2) 다른 src로부터의 간섭
3) multipath 지연(propagation). frequency가 여러 지형지물로 인해 반사되어 들어와, 수신자에게 시간차를 발생하며 돌아옴.
SNR - 노이즈에 대한 신호의 세기. 높을수록 noise에 대해 신호가 강하기에, 더 좋고 error rate가 낮아짐.
physical layer에서 관할하며, 여기에서 power을 높임으로 세짐. 단, power을 높이면 요구에너지 증가.
히든 터미널 문제 - A와 B가, B가 C와 통신하지만 A와 C는 통신 못함.
Signal Attenuation - 비슷함.
CDMA - 유니크한 코드(chipping sequence)를 original data에 삽입해서 encoded signal을 생성. 이를 각자가 만든 다음 sharing하면서 동시에 전파를 쏘면, 수신자는 chipping sequence를 sharing data 중 받고자 하는 것에 정확히 넣으면 original data을 받을 수 있다.
802.11(Wireless LAN) - 멀티플 액세스를 위해 CSMA/CA 사용하는 패밀리. DHCP가 돔.
이것의 LAN 아키텍처 - Base station(=access point, AP)로 접근.
호스트는 AP의 이름(SSID)와 개인 MAC주소가 들어있는 beacon 신호를 받게 된다. 이를 통해 호스트는 특정 AP와 연결되어 걔랑만 연락할 수 있게 됨.
패시브 스캐닝 - 호스트가 대기. AP가 먼저 메시지를 줌.
액티브 스캐닝 - 호스트가 요청.
IEEE802.11 : 멀티플 액세스가 필요. CSMA를 선택하는데, 무선인 경우엔 CD(충돌감지)가 힘듦. 이를 detection이 아닌, 피하는(Avoid) 게 곧 CSMA/CA.
1) DIFS : Idle이면 보내도 된다고 보고 보냄. 채널이 바쁘다고 하면(idle이 아니면), 카운트다운. 타임아웃 시 다시 센싱, idle이면 보냄. 만일 ACK가 오지 않으면, backoff interval이 있다 가정, 다시 카운트다운.
만일 수신자는 frame을 잘 받았으면, SIFS(매우 짧은 시간)동안 기다린 다음 ACK 전송. 히든터미널 문제가 생길 수 있으니, 무조건 ACK 보내야됨.
그러나 이는 비효율적이니, 발전시킨 'Reservation 매커니즘' 활용.
센더가 뭔갈 보내려 할 때, 아주 작은 패킷을 base station으로, CSMA버전으로 보냄(RTS).
뭔가를 보내도 되는지 묻는 프로토콜. 콜리전 일어나더라도 별로 상관없으니 CA나 CD는 안씀.
BS는, RTS패킷 받으면 모든 노드에 브로드캐스팅(CTS-누군가가 보내고자 하니, 나머지는 대기타라).
'Node-to-AP'디바이스가 계속 active하게 있을 필요가 없듯,
Access point가 Sleep모드로 들어갔다가 보낼 노드가 생길 때 active하게 되는 것.
802.15 - 블루투스. 책상 위의 것들을 ad-hoc(no infrastructure)로, 마스터-슬레이브 프로토콜로 무선연결. 보낼게 있으면 마스터에 요청. 마스터가 허락해야 전송.
Cellular Network - 한 base station이 특정 cell을 커버하는 형태. 모바일 유저는 base station 통해 public network에 연결됨. 이 base station이 묶어 연결된 것이 MSC(모바일 스위칭 센터). 이 모든 건 wired network임.
오직 단말기-마지막 hop 사이가 wireless 형태.
이의 접근방법은 1)FDMA+TDMA, 2)CDMA
1) 한 셀을 위해 특정 스펙트럼이 할당되면, 그 특정 스펙트럼이 채널로 나눠짐(FDMA). 그 채널을 TDMA을 통해 각 사람에게 할당.
2) 그냥 CDMA
2세데 무선네트워크 - 일반 핸드폰 서비스(오직 음성). MSC 및 BSS(Base Station System)의 설립.
3 - 데이터서비스 추가. 보이스와 데이터를 분리, 멀티미디어는 인터넷을, 보이스는 기존을 활용.(각자 패러렐하게)
4 - 패러렐하던걸 합침.
홈 네트워크: 퍼머넌트 어드레스를 할당받음. 또한 홈 에이전트라는, mobility func을 수행하는 게 있음.
Visit network : 현재 위치하고 있는 네트워크. 포린 에이전트가 존재, 홈에이전트와 비슷.
임시로 이게 care-of-address라는, 임시 ip를 나의 correspondent에 할당해 통신.
라우터가 permanant address를 일일이 쫓아다니면서 라우팅테이블 탐색(let routing handle it) - 현재는 불가. 모바일이 넘 많음.
let end-systems handle it - 1) indirect 라우팅: 홈 에이전트가, 모바일이 어딨는지 foreign agent통해 care of address를 받아 coreespondent가 연락했을 때 거기로 포워딩
2) direct 라우팅 : 홈 에이전트가, 얘가 어딨는지 care-of-address를 받아와 correspondent에게 알려주고, correspondent가 직접 연락하게.
순번
1) 내가 홈네트워크에 있다 다른 네트워크(visit) 방문. 그곳의 foreign에 자신의 퍼머넌트 address를 제공.
그럼 이를 visit이 home에게 알려주고 care of address제공.
홈은 내 고객이 지금 어디에 있는지, foreign은 누가 내 영역에 있는지를 확인
2) correspondent입장에서는 내 permanent address만 아는 상태. 걔한테 연락하면, 홈은 care of address를 통해 visit network로 연결. 거기의 foreing agent는 나에게 포워딩해주고, 나는 이렇게 correspondent와 연결이 가능해짐.
즉, care-of-address와 permanent address 두 개를 쓰는 상태.
같은 홈이 같은 visit에 있으면 비효율적이게 됨.
permanent address만 쓰게 하는 건 transparnet라 함.
다이렉트 라우팅은,
나랑 통화하려는 애가 아는건 permanent 하나. 그거로 home에 연락시, home은 visit 정보 알려줌. 그를 통해 visit의 나와 연락. 이는 indirect의 triangle 라우팅 문제점은 해결되었으나, 항상 care of address를 써야 하기에, transparency가 깨짐.
앵커(anchor) :
앵커 foreign agent라고 하는, 맨 처음 방문한 visit network를 하나 임시로 이름붙여,
correspondent가 direct하게 그 foreign agent로 오게 함.
home은 아무 역할을(맨 처음 care of address 주기 말고) 하지 않으며,
anchor은 내가 다른 visit으로 옮기면 임시로 home network 역할을 맡게 됨.
다음으로, 그 옮긴 visit에 등록 시, 그 new foreign network의 agent가 care-of-address 받고, 새로운 앵커가 됨(=체이닝 기법)
모바일 IP -
ICMP 프로토콜 : Agent Advertisement 수행.
HLR(home location register) - 내 주소 등을 관리하는 DB.
VLR(visit location register) - 지금 나한테 와있는 놈들 관리.
1) correspondent가 home에 연락.
2) HLR은 DB보고 내 위치(visit network) 파악
3) MSC(모바일 스위칭 센터)가 내 위치 알려줌, home MSC는 2nd leg of call로, visit네트워크로 연결시켜줌.
근데 내가 만약 visit을 이동하면서 바꿨다? 이 때 쓰는게 handoff
Handoff between MSC: 역시 앵커 활용.
멀티미디어 네트워킹
초당 몇 번 샘플링? 이를 양자화함. 보통 256개로.
본래값-양자화된 값=err가 발생.
CBR : fixed된 rate로 인코딩
VBR : 변환 가능한 rate로 인코딩
continuous playout constraint : 네트워크 딜레이가 발생해, 한 프레임 올 떄마다 fix된 딜레이가 오면 되는데, 그게 매번 바뀌면? --> 버퍼 씀.
네트워크 딜레이는 constant가 아님. 따라서, client playout delay를 통해, 데이터를 받아도 좀 기다린 다음에 playout시킴.
이러한 Client-side buffering, playout을 통해,
1) 패킷이 일정시간 버퍼에 찬 다음, tp가 되면 playout 시작
2) 경우에 따라 버퍼가 차거나 비게 될 것(전송 상황에 따라)
3) 그러나 playout 자체는 constant하도록 유지시킴.
평균 fillrate가 playout rate보다 작으면, 버퍼가 비게 되어 화면정지가 발새이
크면, inital playout delay tradeoff라 하는, 양질의 서비스 받게 됨.
그러나 tradeoff가 존재하는데, 버퍼 오래 채우면 처음 시작기간 김/짧게 채우면 금방 시작해도 자꾸 끊김
어플리케이션 레이어에서 error recovery구현, UDP여도 이러한 걸 할 수 이씀(RTP)
VOIP: 떠들 땐 64kbps, 조용할 땐 안함.
하나의 청크를 20msec로 만들어, 8kbytes(=64kpbs)/sec로 전송. 즉, 하나의 청크는 160bytes가 됨.
이 페이로드에 헤더파일을 붙이고, 캡슐화시켜 데이터그램으로 만들어 UDP/TCP등으로 전송.
loss) 네트워크 로스: 라우터에서 오버플로우 시 발생.
딜레이 로스 : 일정 시간 지나서 들어온건 딜레이 로스 처리.
20msec 정도의 딜레이는 그냥 들어와도 됨. 근데 client playout(delay)는 얼마정도로 설정할 거임?
리시버는 chunk가 만들어진 시간(t) 후 q시간 안에 display가 되어야 함. 즉, t+q안에.
만일 chunk가 t+q 안에 들어오지 않았담녀 버림. 그 q의 시간 설정이 중요.
q가 크면, 소리가 한참 뒤에 들려올 것. 작으면, 많은게 드롭됨.
현 네트워크 delay를 파악, 적응적으로(adaptive) 딜레이를 선택.
청크는 20msec 사이에 display되어야 한다. 이를 위해, EWMA를 활용하여,
di: 그 전의 딜레이 타임, ri - ti: 지금 바로 estimate한 딜레이 에 근거해 계산.
Recovery: 다시 보내기. FEC(Forward Error Correction) 활용.
N개의 청크에 1개를 더 보냄(그 청크는 모든 정보를 xor시킨 것). 1/N만큼의 bandwidth over가 일어나는 단점 존재.
위의 piggyback lower quality stream: 한 패킷이 다른 패킷의 정보를 담기.
Interleaving : 하나의 청크를 4개로 쪼개 곳곳에 분산.
하나가 없어져도 다른 것에서 따오기 가능.
bandwidth over은 없으나, 해독이 어려움.
스카이프: 모든 단말이 overlay Network + SuperNode(SN)에 붙어있음.
TCP통해 SN에 단말이 붙어, 서버에 로그인 후, SN통해 IP주소 획득 후 연결하려는 애 정보 획득해 연결됨.
RTP: 실시간 데이터 전송 with UDP. 어플리케이션 layer에서 작동.
오디오 청크에 RTP헤더가 붙음 -> UPD통해 캡슐화(즉, 딜레이에 대한 보장 없이 Best Service만) -> 라우터가 열어보지 않고 그냥 최선 다해 보냄
RTCP: 더 잘 돌게 하는 Control Protocol. 센더와 리시버가 통신 시, RTCP는, 리시버가 이 RTCP통해 정보 전송.
센더는 '시스템 운영을 위해 뭘 해야 할지 필요한 정보 조절'을 함.
RTCP는 RTP의 Bandwidth의 5%이상을 쓰지 않음(ex. 2Mbps가 총량이면 RTCP는 100Kbps. 이중 센더는 25%이며, 리시버는 75%를 활용. 리시버가 n명이면 이 75%를 75/n%로 나눠 활용.)
SIP: 비디오컨퍼런스 등에 활용. 이메일처럼, 상대방의 변치않는 정보 근간해 통신. IP주소는 자꾸 바뀌니까 불안전.
프록시 등에 쓰이기도 함.
H.323과 유사. SIP는 웹, H.323은 전화.
폴링 = {라운드 로빈 순서, 우선순위}
데이터를 전송 시, 기본 스테이션은 보낼 것이 있으면, 각 노드에 메세지를 보낸다.
이 때, 기본스테이션은 대상 장치가 수신 준비가 되었는지 알아야 함.
이를 위해, 데이터 전송 전 선택프레임(SEL)을 생성해 전송하고, ACK를 기다린다.
이 때, 주체가 데이터를 수신할 준비가 되면 각 장치에 전송할 내용이 있는지 물어보거나 폴링해야 한다.
보조스테이션은 전송할 데이터가 있으면 데이터프레임을 전송하고,
그렇지 않으면 음성 확인 응답(NAK)을 보낸다.
"""
순차적으로 송신 요구의 유무를 문의하고,
요구가 있을 경우에는 그 단말 장치에 송신을 시작하도록 지령하며,
없을 때에는 다음 단말 장치에 대하여 문의하는 전송 제어 방식
"""
1) 그냥 노력한다(Best Effort) --> 쉽게 구현, 퀄리티 오브 서비스 보장x, 모든 데이터를 평등하게 취급(~4세대)
2) 달라진 서비스(Differentiated Service) --> 복잡도를 좀 높여, 폴리싱(policing)과 스케쥴링 등을 함. 퀄리티 상승(5세대~)
3) 100% 퀄리티 서비스(Per-connection QoS) --> 복잡도 최상, 이론상 존재하나, 구현 불가함. 가장 서비스 좋음.
디멘셔닝 - 최고의 bandwidth 제공이 최선. 패킷로스 및 딜레이, conjestion 없음. 그러나, 가격 비쌈.
따라서, bandwidth를 dimensioning한다. 어느 정도의 bandwidth 주는게 적절한지 따지는 것.
Providing Multiple classes of service(서비스를, 클래스를 나눠 제공) - 패킷 헤더파일에 ToS(Type of Service)를 넣어, 어느 정도의 서비스를 제공할지 따짐. or 패킷에 따라 트래픽 플로우를 다 다르게 하긴 힘드니, 몇 개의 클래스로 패킷을 몇 개의 클래스로 나눠 서비스(alternative한 방법).
군집화(Granularity) - 서로다른 클래스는 서로다른 서비스로(by ToS비트).
예) 전화(VOIP)는 일정하지만, HTTP는 멀티미디어 등으로 인해 생성되는 패킷량이 더 많다. 이 경우 라우터는 VOIP를 로스시킬 가능성이 높다. 이를 막기 위해, VOIP에 우선권을 제공.
원칙1 - 라우터가 서로 다른 클래스 구별할 수 있도록, 패킷마킹을 한다. & 라우터는 패킷에 따라 처리할 수 있도록 정책을 짠다.
원칙2(폴리싱) - 한 노드 디바이스, 즉 voip가 1Mbps를 넘어 2Mbps... 등으로 더 사용하면(할당된 대역폭을 넘기면), 이를 못하도록 제어.
스케쥴링 - FCFS(First come First Service), Simply Multi-class priority, Round Robin, Weighted Fair Queueing
폴리싱 - 미리 정의된 파라미터값을 정하고 트래픽이 이를 넘지 않도록. 여기서 정하는 건 아래.
1) average rate - 하나의 시간단위에 평균적으로 몇 개 패킷이 나감?
2) peak rate - 어떤 specific한 시간에, peak일때 얼마나 수용가능?
3) burst size - 쉼없이 패킷이 올 때, 트래픽 burst 일어나는 사이즈 얼마?
average rate의 average 내기 위한 시간단위 : 일종의 함정. 초당100패킷과 분당6000패킷은 다름. 갑자기 초당 3000개 패킷이 확 올수도 있음. 이를 위한게 burst size.
폴리싱 메커니즘 - 토큰 버킷(token bucket)으로.
패킷이 라우터 통해 나갈 때, 라우터가 제한을 함. 자기가 어떤 특정 시간에 전송 가능한 패킷의 양을 토큰으로 제한.
버켓에 토큰을 담고, 패킷 하나 나갈 때마다 토큰을 1개 제거 --> 내가 가진 토큰양만큼 패킷을 제어.
그럼 특정 시간동안 몇개의 패킷을 보낼 수 있나? r개의 토큰을 generate 시, 시간이 t면, rt+b(미리 담겨있던 것)
이 토큰 개수를 통해, 더 많은 패킷을 보낼 것과 아닌 것을 제어 가능.
원칙3) 링크를 쪼개, FDMA처럼 하나식 할당. Bandwidth를 fixed시키면, 그거 주인이 안쓰면 낭비되는 것. 따라서,
링크 할당시, 좋은 효율을 내도록.
여기까지가 best effort.
아래는 differentiated service : QoS(Quality of Service)를 원함.
Scalability 보장 필요 : 골든룰. 모든 복잡한건(per-flow management-각 요청한 것의 클래스 지정 and in-profile[이 패킷은 편의를 봐라], out-profile[무시해도 되는 것] 마킹) edge router에서 하게 하고, core 라우터는 simple한 일만(스케쥴링, 클래스 기준으로 선호도 변경)
profile 정하는것 역시 토큰제너레이터(r)가 관여.
클래스-based 마킹 = 클래스별로 서로 다르게 패킷을 마크, 차별화
인트라-클래스 마킹 = 미리 고지된 토큰이 다 소진되면, 높은 priority의 클래스일지라도 non-forming됨.
Diffserv 마켓 = IPv4에선 ToS비트를, IPv6에선 트래픽클래스를 둠. 이것들은 6비트(4비트의 DSCP[Diffrentiated Service Code Point] + 2비트[unused])를 점유. 이를 통해 PHB(한 홉 라우터 내에서의 대접수준) 을 결정
컨디셔닝 = 트래픽 Injection ratio를 결정. 여기에 맞춰 트래픽 양을 조절.
최종 : Per-connection QOS 보장.
원칙4) Call admission: 네트워크가 needs를 다 만족 못 시킬 땐, 블락시킴.
RSVP를 통해, 미리 bandwidth를 예약 후 서비스 시작. 완전히 서비스를 보장.
'애니리뷰' 카테고리의 다른 글
| 고급컴퓨터학현장실습대비 1) 리액트 2강 (2) | 2022.10.18 |
|---|---|
| 이미지처리 잡다한것들 (0) | 2022.05.23 |
| DIP) C++ Opencv로 보간법 (0) | 2022.04.17 |
| 네트워크 4) 라우팅 (0) | 2022.04.16 |
| 네트워크 5) 4계층(Transport Layer) (0) | 2022.04.16 |